One method is to add another column (e.g. |
Dan Guzman replied to morphius on Friday, November 20, 2009 8:37 AM
|
One method is to add another column (e.g. site_id) and use the composite of
site_id and work_order_number_id as the primary key.
Another approach is to use a uniqueidentifier data type for
work_order_number_id so that you can use GUID values as the surrogate
primary key.
--
Hope this helps.
Dan Guzman
SQL Server MVP
http://weblogs.sqlteam.com/dang/ |
 |
|
IMHO GUIDS suck if people ever have to use them, how do you like enteringthe |
Jay replied to morphius on Friday, November 20, 2009 9:19 AM
|
IMHO GUIDS suck if people ever have to use them, how do you like entering
the Microsoft key when you do an install?
You just need a two-part key
work_order_origin char(5),
work_order_number identity (1,1) |
 |
|
I am leaning towards using composite keys. |
morphius replied to Dan Guzman on Friday, November 20, 2009 9:50 AM
|
I am leaning towards using composite keys. Would this yield better
performance compared to uniqueidentifier? |
 |
|
How many rows are you talking about? |
Jay replied to morphius on Friday, November 20, 2009 11:44 AM
|
How many rows are you talking about? If it is under 100,000 per year and
you are using a reasonable PK, performance of the composite key should not be
an issue. |
 |
|
If the work_order_number is incremental, I would expect the composite |
Dan Guzman replied to morphius on Friday, November 20, 2009 11:13 PM
|
If the work_order_number is incremental, I would expect the composite key
approach to perform better than a single random GUID. You'll get less
fragmentation and better locality of reference. It will be a closer call if
you assign uniqueidentifier values using NEWSEQUENTIALID.
--
Hope this helps.
Dan Guzman
SQL Server MVP
http://weblogs.sqlteam.com/dang/ |
 |
|