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've used a similar structure for storing property data, and I think it's fine as long as the table will remain relatively small. An entity-attribute-value (EAV) table like this may consume more space and exhibit slower query performance than a traditional column-structured table, but that shouldn't be an issue for a reasonably-sized set of application properties.

Answer 2

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.

Answer 3

This is fine for small amounts of very infrequently accessed data.

It may actually be better for a user looking at the schema to not see individual app properties.

This reduces problems with schema updates. (App properties are frequently added/removed.)

What it is not suitable for is large amounts of data or frequently accessed data, as there is far more work for the database to do here per retrieve, and more space taken up, than for a conventional schema.