The only real downside is what Dave was talking about -- unless you
have a good reason, why clutter up the database with an extra field and
indexes -- the law of parsimony -- the simplest way is the best way.
But, if you *do* have a good reason (as Nick did) then I am all for
breaking the rules, when justified.
Say, you have 3 dbs
Customer
Product
ProductAndCustomer
ProductAndCustomer is an intersection of the other 2
ProductAndCustomerID PK Identity (autonumber)
CustomerID FK
ProductID FK
DateandTime
OtherIntersectionData
In our app, a customer can reorder a product many times so there can be
many intersections for a given customer and product
The combo of CustomerID and ProductID can't be used for a PK as it is
not unique.
We could use the timestamp as an uniquifer, but that's not a good
choice.
Setting up a separate ID field makes good sense.
Further, when doing drill-downs, we can process the intersection
records alone, or with one (or both) sides of the intersection.
Dick
On Mar 18, 2004, at 9:23 AM, Tangorre, Michael wrote:
> What are some of the downsides to this? Will I experience a
> performance hit
> should I use the additional key?
>
> > Now, the above are valid reasons for including a separate key
> > -- another might be that the T3 record contains intersection
> > data, and/or it is sometimes meaningful to process this table
> > by itself -- where the A & B fields are reference data only;
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
