Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
token
Posting Yak Master
133 Posts |
Posted - 2009-05-09 : 18:01:46
|
I have two tables which are related, but one of them I feel doesn't need a primary key. However I notice that "good" database design means every table should have a primary key. Can anyone advise me given the following scenario:I have a PRODUCTS table that has a column called ProductID (primary key).I have a FEATURES table that has two colums... ProductID and Feature.Basically the FEATURES table contains a new row for each feature related to a ProductID. For example:ProductID | Feature1 2GB Ram1 160GB HDD1 Graphics CardI can't understand why I would need a Primary key for the FEATURES table. But should I have one anyway e.g. FeatureID? |
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2009-05-09 : 20:18:46
|
You can create a primary key on more than one column, in the case of the Features table, use both ProductID and Feature.What might be a better design is to separate the Feature column into a separate table called Features(FeatureID, Feature), and create a new table called ProductFeatures(ProductID, FeatureID). The latter table would still have a primary key on 2 columns, but you'd save some storage since you'd only store the text of the feature once. |
|
|
token
Posting Yak Master
133 Posts |
Posted - 2009-05-14 : 08:49:10
|
thanks robvolk.I got the answer from my own experience. Its best to include a Primary Key even if you THINK you don't need it now. You may need it later.I created a FeatureID primary key just in case. It turns out that I needed it later on when I was performing an UPDATE function and SQL Server needed to know exactly which rows to update.Always create a Primary Key - even if it doesn't make sense now. |
|
|
|
|
|