Using an auto-number as a primary key

[Geoff Cayzer]

At http://www.blueclaw-db.com/tips_tricks.htm I came across a section
which is included below and was hoping for some comment on the
article.

--------------

Almost never use this auto-number field as the primary key of the
table.

If you are thinking of hiring an Access programmer or consultant ask
to see a screen shot of a relationship diagram from an Access database
he/she has built. If you see an auto-number ID field in bold then ask
them 'what will prevent two records with the same data getting into
this table?' If they can't give you a good answer then don't hire
them.
----------------------------

Geoff

[DFS]

Geoff,

I didn't read the whole article, but what you quoted is a simplistic
statement made by someone with no knowledge of database design. What will
prevent two records with the same data from being added to the table is a
unique index on whichever fields constitute uniqueness. This index is
unrelated to the autonumber primary key field.

Many, if not most, databases use an automatically generated integer value
for a primary key in some or most tables. I can't say they're appropriate
in every case, but if I see a database using only semantic keys (these are
primary keys set on fields with system data in them: last name, first name,
job title, etc) it's not hard to find tables where updating the data becomes
difficult because of the primary key structure.

Thinking about my systems, I use a combination of semantic and non-semantic
primary keys. It just depends: on the system, how many tables (if you have
to join 8 tables to get a query with meaningful data in it you may want to
stay away from non-semantic keys), how much data, etc.
Semantic key example:

CodeTable
CodeID

CategoryTable
CategoryID

AirCarriersTable
AirCarrierID

PassengersTable
PassengerID
PassengerName

TransactionTable
CodeID
CategoryID
AirCarrierID
PassengerID

In this case, you end up with a transaction table full of just ID numbers,
and you have to create a query joining all the tables to see meaningful
data.

Here's a discussion on primary keys
http://www.4square.net/papers/NonSemanticKeys.html in which the author
argues for ONLY an autonumber type (non-semantic) primary key.

"Geoff Cayzer" <ca****@optusnet.com.au> wrote in message
news:22*************************@posting.google.co m...

At http://www.blueclaw-db.com/tips_tricks.htm I came across a section
which is included below and was hoping for some comment on the
article.

--------------

Almost never use this auto-number field as the primary key of the
table.

If you are thinking of hiring an Access programmer or consultant ask
to see a screen shot of a relationship diagram from an Access database
he/she has built. If you see an auto-number ID field in bold then ask
them 'what will prevent two records with the same data getting into
this table?' If they can't give you a good answer then don't hire
them.
----------------------------

Geoff

[Randy Harris]

"Geoff Cayzer" <ca****@optusnet.com.au> wrote in message
news:22*************************@posting.google.co m...

At http://www.blueclaw-db.com/tips_tricks.htm I came across a section
which is included below and was hoping for some comment on the
article.

--------------

Almost never use this auto-number field as the primary key of the
table.

If you are thinking of hiring an Access programmer or consultant ask
to see a screen shot of a relationship diagram from an Access database
he/she has built. If you see an auto-number ID field in bold then ask
them 'what will prevent two records with the same data getting into
this table?' If they can't give you a good answer then don't hire
them.
----------------------------

Geoff

Personally, I can't agree with that statement. An auto-number is often a
suitable primary key. The principal function of the primary key is not to
prevent data duplication, though it sometimes does this, but rather, unique
identification of every record in a table. Auto-number is an easy way to
generate unique values.

[Randy Harris]

"DFS" <no******@nospam.com> wrote in message
news:vt************@corp.supernews.com...

Geoff,

I didn't read the whole article, but what you quoted is a simplistic
statement made by someone with no knowledge of database design. What will
prevent two records with the same data from being added to the table is a
unique index on whichever fields constitute uniqueness. This index is
unrelated to the autonumber primary key field.
IMO, what you say is correct, however, concluding that the author of that
statement has "no knowledge of database design", based on a single small
error, is unfair. And probably not correct.
Many, if not most, databases use an automatically generated integer value
for a primary key in some or most tables. I can't say they're appropriate
in every case, but if I see a database using only semantic keys (these are
primary keys set on fields with system data in them: last name, first name, job title, etc) it's not hard to find tables where updating the data becomes difficult because of the primary key structure.

Thinking about my systems, I use a combination of semantic and non-semantic primary keys. It just depends: on the system, how many tables (if you have to join 8 tables to get a query with meaningful data in it you may want to
stay away from non-semantic keys), how much data, etc.
Semantic key example:

CodeTable
CodeID

CategoryTable
CategoryID

AirCarriersTable
AirCarrierID

PassengersTable
PassengerID
PassengerName

TransactionTable
CodeID
CategoryID
AirCarrierID
PassengerID

In this case, you end up with a transaction table full of just ID numbers,
and you have to create a query joining all the tables to see meaningful
data.

Here's a discussion on primary keys
http://www.4square.net/papers/NonSemanticKeys.html in which the author
argues for ONLY an autonumber type (non-semantic) primary key.

"Geoff Cayzer" <ca****@optusnet.com.au> wrote in message
news:22*************************@posting.google.co m...

At http://www.blueclaw-db.com/tips_tricks.htm I came across a section
which is included below and was hoping for some comment on the
article.

--------------

Almost never use this auto-number field as the primary key of the
table.

If you are thinking of hiring an Access programmer or consultant ask
to see a screen shot of a relationship diagram from an Access database
he/she has built. If you see an auto-number ID field in bold then ask
them 'what will prevent two records with the same data getting into
this table?' If they can't give you a good answer then don't hire
them.
----------------------------

Geoff

[DFS]

"Randy Harris" <ra***@SpamFree.com> wrote in message
news:yu**********************@newssvr28.news.prodi gy.com...

"DFS" <no******@nospam.com> wrote in message
news:vt************@corp.supernews.com...

Geoff,

I didn't read the whole article, but what you quoted is a simplistic
statement made by someone with no knowledge of database design. What will prevent two records with the same data from being added to the table is a unique index on whichever fields constitute uniqueness. This index is
unrelated to the autonumber primary key field.

IMO, what you say is correct, however, concluding that the author of that
statement has "no knowledge of database design", based on a single small
error, is unfair. And probably not correct.

True - maybe a little unfair and incorrect.

As I said, I didn't read the article from which that quote came, but it's
definitely not a small error. It's a huge error, which clearly demonstrates
LACK OF (previously I said NO) knowledge of database design. Perusing the
article http://www.blueclaw-db.com/tips_tricks.htm I see the author knows
more than I expected, but still makes some odd and incorrect statements,
such as

"Again, never use the Unique Numeric ID (auto-number) for the primary key
unless it is used as data in other areas of your business (examples would be
Serial_Number_ID, PO_Number_ID)."

I hope you're not the author, Randy.

Many, if not most, databases use an automatically generated integer value for a primary key in some or most tables. I can't say they're appropriate in every case, but if I see a database using only semantic keys (these are primary keys set on fields with system data in them: last name, first

name,

job title, etc) it's not hard to find tables where updating the data

becomes

difficult because of the primary key structure.

Thinking about my systems, I use a combination of semantic and

non-semantic

primary keys. It just depends: on the system, how many tables (if you

have

to join 8 tables to get a query with meaningful data in it you may want to stay away from non-semantic keys), how much data, etc.
Semantic key example:

CodeTable
CodeID

CategoryTable
CategoryID

AirCarriersTable
AirCarrierID

PassengersTable
PassengerID
PassengerName

TransactionTable
CodeID
CategoryID
AirCarrierID
PassengerID

In this case, you end up with a transaction table full of just ID numbers, and you have to create a query joining all the tables to see meaningful
data.

Here's a discussion on primary keys
http://www.4square.net/papers/NonSemanticKeys.html in which the author
argues for ONLY an autonumber type (non-semantic) primary key.

"Geoff Cayzer" <ca****@optusnet.com.au> wrote in message
news:22*************************@posting.google.co m...

At http://www.blueclaw-db.com/tips_tricks.htm I came across a section
which is included below and was hoping for some comment on the
article.

--------------

Almost never use this auto-number field as the primary key of the
table.

If you are thinking of hiring an Access programmer or consultant ask
to see a screen shot of a relationship diagram from an Access database
he/she has built. If you see an auto-number ID field in bold then ask
them 'what will prevent two records with the same data getting into
this table?' If they can't give you a good answer then don't hire
them.
----------------------------

Geoff

[Randy Harris]

"DFS" <no******@nospam.com> wrote in message
news:vt************@corp.supernews.com...

"Randy Harris" <ra***@SpamFree.com> wrote in message
news:yu**********************@newssvr28.news.prodi gy.com...

"DFS" <no******@nospam.com> wrote in message
news:vt************@corp.supernews.com...

Geoff,

I didn't read the whole article, but what you quoted is a simplistic
statement made by someone with no knowledge of database design. What will prevent two records with the same data from being added to the table

is

a unique index on whichever fields constitute uniqueness. This index is
unrelated to the autonumber primary key field.
IMO, what you say is correct, however, concluding that the author of that statement has "no knowledge of database design", based on a single small
error, is unfair. And probably not correct.

True - maybe a little unfair and incorrect.

As I said, I didn't read the article from which that quote came, but it's
definitely not a small error. It's a huge error, which clearly

demonstrates LACK OF (previously I said NO) knowledge of database design. Perusing the
article http://www.blueclaw-db.com/tips_tricks.htm I see the author knows
more than I expected, but still makes some odd and incorrect statements,
such as

"Again, never use the Unique Numeric ID (auto-number) for the primary key
unless it is used as data in other areas of your business (examples would be Serial_Number_ID, PO_Number_ID)."

I hope you're not the author, Randy.

No, definitely not. I make no claims to being an expert. I agree as well,
however, that second statement above is also poor advice. Perhaps a more
serious error than the earlier one. I believe that auto-number keys should
never, under any circumstances, be used to contain data. So called "smart
keys" are very poor design.