You have a form, say, a registration form. In this form, you have these common fields, example Name, Age, Address, State, Country and etc. So, in your database design, how do you go about it? Create just one table to store all these fields? Something like below?
|3||Chee Weng||24||12-A-1||Pahang||Malaysia||Hong Kong|
Now, consider these few questions:
To solve the above problems, you need to use an UPDATE query to change all records which has the value Wilayah Persekutuan to KL Persekutuan. Then you need to go to add registration form page to change the hardcoded value, as well as edit registration form and view registration form code. Maintenance nightmare!
Let’s improve the design by having some lookup tables (the word “lookup” is my own term). First, we identify which fields we should have a lookup tables. I pick State, Present Country and Country Born. So, I need to create two lookup tables. Two because Present Country and Country Born can share the same table. Let’s have a simple design for these lookup tables.
Both fields can just be varchar and below are some sample data
|KL||W.P. Kuala Lumpur|
(View a complete country code)
Right now, you can go back to your add registration form code, and you can use these look up tables to populate instead of using hardcoded values. You can use the State_Code and Country_Code as the value to store in user table, which becomes below,
You can also use these lookup tables to populate values for edit and view page.
What happen when you realize that you are going to have a lot of lookup tables? Then, you can consider using just one resource table.
One reply on “Hardcoded Values vs Lookup Tables”
[…] Steve Finding « Hardcoded Values vs Lookup Tables […]