Re: non numeric primary key

From: <markp7832_at_my-deja.com>
Date: 2000/01/17
Message-ID: <85u797$il5$1_at_nnrp1.deja.com>#1/1


In article <3881EE57.CD29B093_at_arcavia.com>,   Kyle Lahnakoski <kyle_at_arcavia.com> wrote:
>
>
> Fernando wrote:
> > I've been told that choosing a non numeric field as a
 primary
> > key would hurt performance, is this true? O:-)
>
> Yes. In most DB implementations the number of bits used to store an
> number is smaller than used to store a string (Space). Second, the
> algorithm used to compare strings is less efficient, per byte, than
 it
> is for numbers (Speed).
>
> There could be implementations that are specifically suited for
> comparing short strings (4-8 chars) just as fast as numbers, but I
 would
> imagine they are rare.
> --
The most common rdbms in the World is Oracle and Oracle stores all numbers in an internal platform independent format, scientific notation, so no it is not necessarily more efficient to use a number instead of a character column. Most of the time when people refer to numbers as being more efficient than character fields they expect the number to be stored as a machine binary, but I have friends who work on databases that support tables with row counts heading to the tens of billions. A 32 bit integer does not cut it.

More importantly the key to a table should be the column(s) that support the business requirements. End users have access to a lot of adhoc tools and they like to query on business fields. Things like order numbers, part numbers, receiver numbers, and purchase order numbers, all of which may have non-numeric characters in them.

Giving every table a numeric key is an academic concept that has no real business justification. In the real world systems need to be understandable to the end-user, maintainable, and perform with reasonable efficiency.

--
Mark D. Powell  -- The only advice that counts is the advice that
 you follow so follow your own advice --


Sent via Deja.com http://www.deja.com/
Before you buy.
Received on Mon Jan 17 2000 - 00:00:00 CET

Original text of this message