Re: Artificial Primary keys
Date: 23 Jan 2002 10:34:59 -0800
>> The identifier for an employee is an arbitrarily chosen 'next
avaliable number', because that's an easy way to guarantee uniqueness. <<
But it costs you verifiability. How do you know that number 123 is really "John Smith" and pay salaries and taxes to him? Did you put him in the database twice? Did someone else get his number? Who knows? With SSN, which you have to have anyway, you can verify it with other documents and the tax boys.
>> However, the real-world unique id for an Assignment is 'employee-id
|| start-date'. Other people's thinking in this area is that a short, numeric key is easier to maintain (marginally) and it will perform much better for the joins that are to come. <<
Join performance is a Red Herring these days. Most computers have a long word size, so we are not back in the days of 16 bit minicomputers when Sybase was just starting on UNIX on DEC PDP-11s and Data General Novas were the neatet thing on Earth. You really have to have a really long, ugly key for it to slow things down (SQL Server GUID, for example). Your algorithmic key is easy to verify, unique within each job to which an employee is assigned. I like it. Received on Wed Jan 23 2002 - 19:34:59 CET