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?
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.