A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Database Design
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

AutoNumber vs. Natural Primary Keys



 
 
Thread Tools Display Modes
  #1  
Old January 7th, 2010, 09:13 AM posted to microsoft.public.access.tablesdbdesign
Tokyo Alex
external usenet poster
 
Posts: 34
Default AutoNumber vs. Natural Primary Keys

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.

  #2  
Old January 7th, 2010, 10:58 AM posted to microsoft.public.access.tablesdbdesign
Allen Browne
external usenet poster
 
Posts: 11,706
Default AutoNumber vs. Natural Primary Keys

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" wrote in message
...
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.

  #3  
Old January 7th, 2010, 02:40 PM posted to microsoft.public.access.tablesdbdesign
Fred
external usenet poster
 
Posts: 1,451
Default AutoNumber vs. Natural Primary Keys

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.
  #4  
Old January 7th, 2010, 03:08 PM posted to microsoft.public.access.tablesdbdesign
Keith Wilby
external usenet poster
 
Posts: 812
Default AutoNumber vs. Natural Primary Keys

"Fred" wrote in message
...
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

  #5  
Old January 7th, 2010, 11:13 PM posted to microsoft.public.access.tablesdbdesign
David W. Fenton
external usenet poster
 
Posts: 3,373
Default AutoNumber vs. Natural Primary Keys

"Allen Browne" wrote in
:

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/
  #6  
Old January 8th, 2010, 10:03 AM posted to microsoft.public.access.tablesdbdesign
Tokyo Alex
external usenet poster
 
Posts: 34
Default AutoNumber vs. Natural Primary Keys

Dear Allen, David, Fred and Keith,

Thanks very much for the responses. Gives me some things to think about.

Alex.


"Tokyo Alex" wrote:

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.

[Snip]
  #7  
Old January 8th, 2010, 05:22 PM posted to microsoft.public.access.tablesdbdesign
Fred
external usenet poster
 
Posts: 1,451
Default AutoNumber vs. Natural Primary Keys

I'd say the same thing. I should have clarified that post was actually just
about the "everything else" cases.
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 04:33 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.