disagreeing with Dave - your proposed approach of adding a surrogate key is
our standard way of doing things. Even when the table is a simple
intersection table consisting of nothing but 2 foreign keys, we always make
the primary key an IDENTITY/autoincrement field. We never use a compound key
as the primary key (though of course we use them as secondary keys). Why?
Because it maximizes the amount of our code (including our automated
ER-modelling-to-schema-generation app) that can work exactly the same way
for different tables and even different applications. In conjunction with
rigid standards for table & column naming, it adds up to more productivity
in the long run.
Nick
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
