Re: Sequence Numbers as Primary Keys
Date: 1995/09/26
Message-ID: <449teu$opj_at_dingo.cc.uq.oz.au>#1/1
aranders_at_kosepc01.delcoelect.com (Alan Anderson) wrote:
>>The IT group claims that their C++ program will be much more efficient with fixed-length
>jhagans_at_telerama.lm.com (^^^^^^^) writes:
>>[...]
>>unique identifiers.
>Yep. That's what we decided too. "We" are responsible both for the
>database and the tools written to talk to it, so we were pretty confident
>that we were making the right decision.
>>The DBA group refuses to use sequence numbers claiming that they are not "business
>>data" and do not belong in the database.
>After having used the database for several years, we have changed our
>mind and now agree with your DBA group. Even if the programs ARE more
>efficient -- and there's actually no reason to think they are -- the
>arbitrary ID numbers being used as primary keys make it very difficult
>to understand and maintain the programs.
I find this difficult to believe... Are you saying that a combination of Customer Name, Address, etc. etc. makes a program easier to understand than say a customer number with the other columns as attributes.
Again I suggest you read Relational Database Writings by C. J. Date for an understanding of surrogate keys used in tables as the primary key. They aid in saving disk space as indexes can kep smaller and faster. The arguments in favour of using a surrogate intelligently far outway the arguments for using composite primary keys.
>>The database has probably around 50 tables with an estimated 6 million hits a day;
>>However it is only a few tables (7 or less) that will be getting the majority of the hits. The
>>composite key in these tables is quite large, usually 5 or 6 columns to make the row
>>unique.
>Don't try to optimize the data structure in advance. Listen to the
>DBA group and let them figure out what data belongs in which tables.
>If you have performance problems, work them out within the framework
>of the "correctly" normalized data. Don't fall into the easy trap of
>structuring your data to fit a particular way of using it. If you do
>try to optimize for an application, other natural queries on the data
>can be downright difficult.
>>Any insight to this matter would be greatly appreciated.
>I hope I helped.
>= === === === = = = === === === === = = === = = = === = = === =
># Alan Anderson # Ignorance can be fixed, but stupidity is permanent. #
> (I do not speak for Delco Electronics, and DE does not speak for me.)
-----------------------------\ooOoo/----------------------------------- Gordon Hooker MACS PCP ,--_|\ 25 Clarke Street, Ripley, Queensland, 4306, Australia / \ gordonh_at_acslink.net.au \_.--._/ mobile: 018883835 phone: 61-7-2889716 V -----------------------------------------------------------------------It is far better to remain silent and appear a fool, than to open ones mouth and remove all doubt... Received on Tue Sep 26 1995 - 00:00:00 CET