I want ot create database table in which I can store application settings. Which of the two table designs is better:
- Store the settings in a column and one row for key - something like this:
- Store the settings in only two rows - something like this:
Which of the two is more appropriate for storing application settings?
Los mejores deseos
preguntado el 10 de marzo de 12 a las 14:03
Use the second method. Obviously it is far more scalable. You will never need to add additional columns when you need to add more options.
I would only advocate the first method if the options are very limited and fixed, and all have different data types. That's an area where the two differ considerably - if you have a big mix of numeric and character columns, you have really no choice with the second option but to store them all as
VARCHAR. However, for a settings table that will have a very limited number of rows and won't be subject to a lot of
UPDATE, that probably isn't a big issue.
You would not want to use the second method for a regular table (not storing mostly static application settings) that needs to be highly accessible, or used for calculations for example, where you would constantly need to be type casting values to manipulate them.
For static data infrequently accessed or modified, the second method works well though.
It really depends on how often these values change and how varying there types are:
If for example you have a finite number of settings of many varied types, then the horizontal layout is better, because you can specify each type. But everytime you want to add a new one you'll h ave to alter the table.
Conversely if you have many different types and people have many different arrangements of the settings, and perhaps even you know that new ones will continue to come in the future, then the second listing will be better. The trouble though is that you'll be stuck with varchar(nnn) type for each value, so the db won't be able to help you with the typing very much.
Option 1 is "better" until there are a lot of settings (ie: dozens, hundreds). If there son "a lot of settings" there may be better ways to model them.
As one example, maybe that information doesn't even belong in this system and could be pushed to its own independent system that manages that kind of data for all applications.
As another example, maybe some of those settings actually could relate to something else in your system, maybe even a concept that you haven't yet introduced; IE: maybe that data varies by Season, or by Company, and you haven't thought to model those types yet.
I would save Option 2 for cases where it's truly necessary (ie: you have thousands of values to write). Yes, it's very flexible, but it also loses a lot of semantic meaning, and is overall a failure of your data model. (It's actually a degeneracy of the use of the database and/or ORM and should only be chosen very carefully.)