Am Sonntag, den 23.09.2007, 02:49 -0400 schrieb Andrew Jensen: > One thing, you might want to create a unique index on ( MasterID, > DetailID ) in the MasterDetail table? > > If not then you are allowing yourself to create duplicate records.
This could be helpful, I'll add it in the next session. > For that matter you could of dropped the the IDENTITY field in the > MasterDetail table altogether and just had the two FK values, and used > both as the PK. I mostly avoid concatenated keys. They have some attributes that tend to shoot your feet of which the worst is having to discriminate between simple and concatenated keys. Using base that is (or may be, never tried) no problem, but when you have to write code for a database it will. Imagine writing a small persistence layer for an application. That task is much easier and even more readable and thus understandable if all keys are simple ones. The downside is having to use unique keys on some more columns. I don't see a problem therein, only a few additional bytes in the underlying database. And since indexing is handled anyways it won't bring in special cases to consider. Sort of a "best practices" opinion. Marc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
