Re: Rule when primary key is needed?
From: Craig Alexander Morrison (reply_at_newsgroups.com)
Date: 08/15/04
- Next message: Craig Alexander Morrison: "Re: Rule when primary key is needed?"
- Previous message: fredg: "Re: Different Color for Negative and Positive Value"
- In reply to: Roland Bengtsson: "Rule when primary key is needed?"
- Next in thread: Roland Bengtsson: "Re: Rule when primary key is needed?"
- Reply: Roland Bengtsson: "Re: Rule when primary key is needed?"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 15 Aug 2004 15:58:06 +0100
Roland
<<<> Is there a rule when primary key is needed in a table?>>>>
When you create a table that is part of a "relational" database.
<<<<> For example I have small tables with 5 - 20 posts. These are used with
> Comboboxes in another table.>>>>
If you are talking about lookup values for a main table then you should
define a primary key and consider enforcing RI cascade update only on the
relationships between the "lookup" tables and the "main" table. This will
ensure that your main table can only contain valid values constrained by the
records in the "lookup" table and that you cannot delete a value from the
"lookup" table that has been used by a record in the "main" table.
The first part (after defining what you want to record) of designing a
database is to normalise the data that you wish to record in it. An early
part of the normalisation process is to choose the primary key for the data
that is to be normalised.
I am not sure what online references are available you may wish to check the
Access 2002 Knowledge Base article 283878 dated 10 October 2003. (Referenced
on MSDN Library DVD July 2004)
If you have Access 2003 Developer Extensions (ADE 2003) there is a
whitepaper called Understanding Normalization dated November 2002, the file
name is NORMALZE.MHT. This has been written by Mike Hernandez of Microsoft
and author of the book "Database Design for Mere Mortals" which I not read
for obvious reasons (vbg) :-) However, I would expect to be a good starter
based on the document that I have read that came with the ADE 2003
These are very similar and fairly simple introductions the whitepaper is a
bit more detailed, the KB Article does not discuss the normal forms above
Third (not required in many designs but worth knowing for when it is
needed). There may be other sources many will be wrong to very wrong these
are a fairly good starter.
<<<<I realize now that a key isn't needed in the small tables.>>>>
No, the size of the table has little to do with it, it is whether this table
is part of a relational database or not. A "lookup" table for a "main" table
is part of a relational database.
If you are not creating a relational database and say just creating a set of
application tables or temporary tables just about anything goes. Although
one must recommend that you do define the primary key even then or at least
an Index that is unique and does not permit nulls, otherwise what is to stop
you creating duplicate records.
Please note that although Access does allow you to create a table without a
primary key the practice is frowned upon and breaks the rules of
normalisation which can only cause you trouble in the long run.
-- Slainte Craig Alexander Morrison "Roland Bengtsson" <roland.bengtssonsf@home.se> wrote in message news:49ceb5c5.0408150515.11d5e202@posting.google.com...
- Next message: Craig Alexander Morrison: "Re: Rule when primary key is needed?"
- Previous message: fredg: "Re: Different Color for Negative and Positive Value"
- In reply to: Roland Bengtsson: "Rule when primary key is needed?"
- Next in thread: Roland Bengtsson: "Re: Rule when primary key is needed?"
- Reply: Roland Bengtsson: "Re: Rule when primary key is needed?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
