Good idea to have a property table in a database?

Question

Often, when I need to save system properties, such as administrator information, versions, etc., I use a flat file (database.properties, init.properties, etc.). This seems common in other programs that I see and use daily.

Sometimes a flat file is not ideal for a number of reasons. Deploying a web application to multiple clients is often fraught with limitations. In these cases, I use a database table to store information. For example, let's say I have some admin data that I want to save, and maybe some features of my environment. I could 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 understand that this interrupts SQL input and allows all types of types to be stored as strings. Is this good practice or am I doing it wrong?

If not, how should I store this type of information?

Answer 1

I used a similar structure to store these properties, and I think this is normal as long as the table remains relatively small. An entity-attribute-value ( EAV ) value like this can consume more space and demonstrate slower query performance than a traditional table, a structured table, but this should not be a problem for a reasonable application size.

Answer 2

I think this is normal, but you might think about caching your data in memory when you read it so you don't have to go back to the database. If you cache your data, save it where your updates become easier. The advantage of storing data in your database is that it would be easier to maintain or create interfaces for managing these properties, especially after you start using the distributed environment for your application.

Answer 3

This is normal for small volumes of very rarely received data.

In fact, it might be better if the user looks at the diagram so as not to see the individual properties of the application.

This reduces problems with updating the schema. (Application properties are often added / removed.)

What is not suitable for it is large amounts of data or frequently used data, since the database here requires much more work for each extraction and more space than for the usual scheme.