GenDotNet Tools (at CodePlex) Fail with AdventureWorksLT

Published Thu, Jun 12 2008 11:18

AdventureWorksLT might look like a good database to get started with if you want to look at the GenDotNet tools (they are still in a very alpha state), but its not. The reason is the use of multi-part primary keys. I don’t know how much to support these in the tool, so for now they just aren’t supported.

The underlying question is whether your many-to-many tables should have their own primary key and use the parent primary keys as logical keys, or whether the parent primary keys should be combined into a multi-part primary key. Because my many-to-many tables often have, or evolve into having a payload, I use the first approach. The second becomes relatively complex at a number of points in the generation process.

If you feel multi-column primary keys are tremendously important or valuable, I'd love to know why.

For now, multi-column primary keys and tables without primary keys are simply not supported.

by Kathleen

Comments

# Michael C. Neel said on Wednesday, June 25, 2008 2:54 PM

I have, upon rare occasion, used a multi-column primary key.  The cases have been I have a table with entries repeating at set times (a table for a real-time dashboard for example) that the primary key is a time stamp coupled with a foreign key the time sensitive data is for.  The reason is data integrity - I can't have two records at the same time for the same foreign key.

I could have done the same with a constraint on the fields, so I can't say this is a must have feature.  Like you, in a many-to-many table the risk/odds of having some meta-data about the relationship is high enough I go ahead and create a primary key for the many-to-many table.

# Christopher Zei said on Thursday, December 11, 2008 2:26 PM

Multi-column primary keys are tremendously dumb. Anyone using Multi-column primary keys has never heard of foriegn keys.

# Christopher Zei said on Thursday, December 11, 2008 2:37 PM

Mike...you should have used 'Id' int identity column as the primary key.  So your table would have had three columns: PK, timestamp, FK

Many-to-many relationships should use a third table to defines the relationship...it would contain Id as the PK and the two FKs.

Leave a Comment

(required) 
(required) 
(optional)
(required) 
If you can't read this number refresh your screen
Enter the numbers above: