Prev: Design theory for maintaining historical address communication
Next: Lookup fields referring to tbls w/o relationship
From: Tokyo Alex on 7 Jan 2010 03:13
Dear all,

As a relative newbie to the art/science of database design, I was wondering
if there was any consensus view on whether it's better to use an AutoNumber
field as primary key for a table rather than select a (human-understandable)
natural key, assuming one exists that you can guarantee will be unique.

Does the situation change between a 'main' table containing entity data
(tblCustomers, e.g.) and a lookup table you're using to store values for a
combo box?

For that matter, is there any situation where you might prefer to use a
random AutoNumber instead of an incremental one?

Any ideas and advice very much appreciated.

Thanks,
Alex.

From: Allen Browne on 7 Jan 2010 04:58
You will find people who strongly argue for natural keys rather than
surrogates where a simple, natural key exists. You will also find people who
always use an AutoNumber, even if there is a simple, obvious, unique,
required field that could do the job.

My personal approach is to use the natural key (rather than an autonumber)
in lookup tables. If the category name is required and unique, why not use
it? Typically I'll limit these to 24-character. You probably realize that
string matching is slower than numeric matching, but I don't find any
measurable performance difference (probably because it's indexed anyway.)
Cascading updates take care of the need to change the category name later
(e.g. if misspelled.)

A side benefit of doing this is that it avoids some of the problems Access
has with combos where the bound column is hidden.

Some developers avoid natural keys so they can write generic code that
accepts numeric key value (i.e. they don't want to write code that has to
handle Text or number values depending on which table you're using it on.
This is a non-issue for me, as I rarely pass a simple value to a function. I
find that the code is much more generic if I pass a WHERE clause rather than
a value, as this copes with more complex conditions (e.g. tables that have a
compound key.)

In general, I use autonumbers for the main tables (e.g. clients.) I find
this avoids making unjustified assumptions about what data will be unique
early in the design process.

Random autonumbers are useful if you need to replicate. I almost never use
them.

HTH.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.


"Tokyo Alex" <TokyoAlex(a)discussions.microsoft.com> wrote in message
news:A4E01061-F09C-40DE-88FA-D8575567E9ED(a)microsoft.com...
> Dear all,
>
> As a relative newbie to the art/science of database design, I was
> wondering
> if there was any consensus view on whether it's better to use an
> AutoNumber
> field as primary key for a table rather than select a
> (human-understandable)
> natural key, assuming one exists that you can guarantee will be unique.
>
> Does the situation change between a 'main' table containing entity data
> (tblCustomers, e.g.) and a lookup table you're using to store values for a
> combo box?
>
> For that matter, is there any situation where you might prefer to use a
> random AutoNumber instead of an incremental one?
>
> Any ideas and advice very much appreciated.
>
> Thanks,
> Alex.
>
From: Fred on 7 Jan 2010 08:40
One other advantage of autonumber keys that is probably too obvious to
mention is that it takes no work, skill or carefulness for the person to
enter and enter it properly.

One other advantage is that this that this number (relied upon for DB
operation) can't be "messed with" by others. For example, if you use a part
number or a membership ID number as a PK, and then some department that
controls part numbers or membership ID numbers says "oh, we changed/corrected
that number" they are just changing a piece of data rather than a PK.
From: Keith Wilby on 7 Jan 2010 09:08
"Fred" <Fred(a)discussions.microsoft.com> wrote in message
news:C9A6A0C8-E81A-4D7F-BE1D-23F8E060299B(a)microsoft.com...
> One other advantage of autonumber keys that is probably too obvious to
> mention is that it takes no work, skill or carefulness for the person to
> enter and enter it properly.
>
> One other advantage is that this that this number (relied upon for DB
> operation) can't be "messed with" by others. For example, if you use a
> part
> number or a membership ID number as a PK, and then some department that
> controls part numbers or membership ID numbers says "oh, we
> changed/corrected
> that number" they are just changing a piece of data rather than a PK.

FWIW my take on this is similar (if not the same) as Allen's - I use a
natural key for a look-up table and an AutoNumber for just about everything
else.

2p supplied :)

Keith.
www.keithwilby.co.uk

From: David W. Fenton on 7 Jan 2010 17:13
"Allen Browne" <AllenBrowne(a)SeeSig.Invalid> wrote in
news:uWcTp$3jKHA.5520(a)TK2MSFTNGP06.phx.gbl:

> Random autonumbers are useful if you need to replicate.

I can't say that I'd recommend that anyone choose random
Autonumbers. Replication *forces* you to use them, and in that
context it's fine.

One scenario where it might be valuable is if you want to spread new
records out across many data pages. Since Jet/ACE tables are stored
in PK order (clustered), sequential Autonumbers will place all the
recent records in the last data pages, whereas a random Autonumber
will distribute them evenly through all the data pages.

However, you don't really get the benefit of that until after a
compact, because it's only after a compact that the whole table is
re-written in PK order.

I've contemplated trying it, but have never had an app where there
was enough contention for data pages for it to matter.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
 |  Next  |  Last
Pages: 1 2
Prev: Design theory for maintaining historical address communication
Next: Lookup fields referring to tbls w/o relationship