Reputation: 85765
I Started of thinking that I would just manually entering in my data through ms sql for a project I am working on(this is a prototype/ proof of concept project) but after designing the database I see it's just going to be a pain and probably won't save me any time, so I am going to develop a form that I can fill out and have it save to the database.
When I was thinking of manual entering data I designed my database like this
Product table has one Country and a Country Table can have many Products.
I was trying to make sure there would be no typos as I would have to hook it up to an existing Country vs just having a field call Country in the products table and open it up to typos.
Now since I am going to enter it in through a form, I am wondering is there really a point to have this separate table in this case?
I was thinking of instead put it in the product table but in my C# code create an enum called Country with the valid Countries list. So this should stop any typos as I would probably have it as a dropdown and if it can't convert into the enum it would fail.
I think in this case it makes more sense to do this versus having the separate table called Country with an PK and Name field.
I wanted to hear other peoples thoughts though.
Upvotes: 0
Views: 91
Reputation: 44931
A separate table which uses a non-sensical key (which could be an enum internally or an identity column) and a display value is the best design for the following reasons:
1) If a country name changes (which is a not-infrequent event recently) or is added, you won't have to recompile.
2) If your application is used in different countries, they will almost certainly have different spellings for other countries, in which case it is much easier to update the database than produce a different version of your application for each country it is sold in.
Upvotes: 1