Is it a bad idea to have a property table in a database?

Question

Often, when I need to store system properties like admin info, versions, and so on, I use a flat file (database.properties, init.properties, etc). This seems common in other programs that I see and use on a daily basis.

Sometimes a flat file isn't ideal for a number of reasons. Deploying a web app to numerous clients often comes with limitations. In these cases, I use a database table to hold the information. For example, let's say I have some admin data that I wish to save, and perhaps some specifics about my environment. I might do something like this:

property_entry_table

[id, scope, refId, propertyName, propertyValue, propertyType] 
1, 0, 1, "DB_VER", "2.3.0", "FLOAT"  
2, 0, 1, "LICENCE", "88475", "INT"  
3, 0, 1, "TOP_PROJECT", "1", "INT"   
4, 0, 1, "SHOW_WELCOME", "F", "BOOL"  
5, 0, 1, "SMTP_AUTH", "SSH", "STRING"  
6, 1, 1, "ADMIN_ALERTS", "T", "BOOL"

I realize this breaks SQL's typing and allows me to store all sorts of types as strings. Is this good practice or have I been going about this the wrong way?

If not, in what way should I be storing this type of info?

Answer 1

I think this is fine but you might want to consider caching your data in memory when you read it so that you don't have to keep going back to the DB. If you cache your data then store it wherever will make your updates the easiest. The advantage of housing the data in your DB is that it might be easier to maintain or create interfaces to manage those properties especially once you start to use a distributed environment for you application.