November 26, 2007 at 9:27 pm
Hi All,
My two questions relate to this schema and documentation.
Why is a composite PK needed for the SalesOrderDetail table when SalesOrderDetailID is already an identity column?
Second, is it ideal to have a separate index for the SalesOrderID column instead of using the composite index when joining to the SalesOrder table?
Thanks.
--Lenard
November 27, 2007 at 2:53 am
lenardd (11/26/2007)
Hi All,My two questions relate to this schema and documentation.
Why is a composite PK needed for the SalesOrderDetail table when SalesOrderDetailID is already an identity column?
Second, is it ideal to have a separate index for the SalesOrderID column instead of using the composite index when joining to the SalesOrder table?
Thanks.
--Lenard
At first glance I cannot really see that both columns are required for the primary key because, as you say, SalesOrderDetailID is an identity column and typically identity columns are used as primary keys. However, just because a column is an identity column it doesn't mean that uniqueness is enforced (or intended). For example, if the identity field is reseeded then you'd potentially get duplicates in there. So perhaps the designer had some reason for doing it this way (I can't think of why but it's possible).
As for the index... as it stands, any joins will result in an index scan if you're only using SalesOrderID to join on. Therefore, and index on SalesOrderID would get around this problem.
Hope that helps,
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply