Merlin Moncure wrote:
> In the context of this debate, I see this argument all the time, with
> the implied suffix: 'If only we used integer keys we would not have
> had this problem...'. Either the customer identifies parts with a
> part number or they don't...and if they do identify parts with a
> number and recycle the numbers, you have a problem...period.
On the contrary. You create a new record with the same part number. You mark the old part number "obsolete".
Everythingelse (the part's description, and all the relationships that it's in, such as order history, catalog
inclusion,revision history, etc.) is unaffected. New orders are placed against the new part number's DB record; for
safetythe old part number can have a trigger that prevent new orders from being placed.
Since the part number is NOT the primary key, duplicate part numbers are not a problem. If you had instead used the
partnumber as the primary key, you'd be dead in the water.
You can argue that the customer is making a dumb decision by reusing catalog numbers, and I'd agree. But they do it,
andas database designers we have to handle it. In my particular system, we aggregate information from several hundred
companies,and this exact scenario happens frequently. Since we're only aggregating information, we have no control
overthe data that these companies provide. If we'd used catalog numbers for primary keys, we'd have big problems.
Craig