Why store lookup values (combobox values) in the database instead of having them on the html page?

What are the typical arg开发者_开发百科uments in support of storing combo-box values (static lookup values (strings etc.) for an application) in database vs storing them right into the html page itself ?

The reason is to separate your data from the UI.

The purpose of placing data in a single location is to make change, fixes, and updates to a site easier. If you have 10 forms and each needs a state drop down then adding a state later would require changing the text on 10 pages.

Even with just one drop down having the separation makes maintenance easier.

The best argument, I think, is that keeping those values in the database means that the values on the page are always in sync with what should be in the database, or what values are allowed to be selected for insertion into the database.

Say you have a list of colors you can select. On the HTML page, you allow the user to select 'red', 'green', 'blue', and 'yellow'. The database reflects this.

Several weeks later, you have added the functionality for purple, as well. So you allow the user to select 'purple' on the HTML page, but forget about the database. Some user selects 'purple' and an attempt is made to insert their selection into the database, but you get a foreign key constraint error because 'purple' is not a valid value currently in the database!

Several weeks later, functionality for 'yellow' has been removed. This time you remember to remove yellow from the database, but forget about the HTML page. So a user selects 'yellow' and an attempt is made to insert their selection into the database, but you get the same foreign key constraint error!

Another week later, you add functionality for 'pink'. This time, you remember to add it to the database, but forget about the HTML page. Now, users are missing out on the cool 'pink' functionality that the database allows because the UI was not updated!

Simply retrieving possible values from the database means that only the database needs to be updated in cases like this.

Because look-up values can change over time. It is very simple to add one to a database, then if you have coded things correctly it will also just appear in the UI. Frequently look-up values can also be used in other operations, so having them stuck in the UI (especially one that is only "available" after being served by IIS) makes them unreachable - so it is a Very Bad Practice.

It is also good practice to define the list in one place, before using it in many (makes for easier updates), so the database is a good place for this. If the database is not suitabl or is unavailable, then you could use another mechanism like enumerations declared in one of your assemblies or shared modules.

Another reason to store the lists in the database is that the list may change. Someone will decide to change one of the existing items in the list, or they will want to add or drop an item in the list.

It is easier to change the data in the database than it is to redeploy a new version of the web page.

When you use these values on several pages, it is hard to maintain the list if one of these values changes or if a value is added or deleted.

• Separation of data and presentation, so you can present your data in multiple ways
• Easier to keep data current when it is stored only in one place.
• Easier localization.
• Easier filtering, if you add metadata to the db