View Single Post
  #26  
Old January 24th, 2008, 10:24 AM posted to comp.databases.ms-access, comp.databases.theory,microsoft.public.access, microsoft.public.access.tablesdbdesign,microsoft.public.sqlserver
JOG
external usenet poster
 
Posts: 30
Default Separate PK in Jxn Tbl?

On Jan 24, 7:03*am, "Brian Selzer" wrote:
"Tony Toews [MVP]" wrote in messagenews:6l5gp3hle4cn2lin154h4ip0288b0pgl0v@4ax .com...

"Brian Selzer" wrote:


Only an idiot would have a rule for no particularly good reason. *Only an
imbecile would follow such a rule. *A strong argument can be made for
using
autonumber primary keys--especially if the target DBMS doesn't support FOR
EACH ROW triggers--but to just blythely add them for no particularly good
reason is a recipe for disaster.


My reasons are, in my opinion, good reasons. *Not great but good. *You
don't like
them? *Tough.


So now they're good reasons? *In your earlier post, you said they weren't
good reasons. *Can't you make up your mind? *You also haven't stated your
reasons. *How can I like them or not like them? *I don't know them!


No, it looks like Tony's reasons are secret, and may only be gleaned
from a romantic evening of fine wine and barry white.


A clear understanding of how and when they
can be used and why is critical or you run the risk of a corrupt database.


Umm, not that you care I'm sure but my web pages on Microsoft Access
corruptions
http://www.granite.ab.ca/access/corruptmdbs.htmare the definitive
resource on the
web. * And there have never been any Access corruptions during to
autonumber primary
keys that I can recall. *And I've likely read just about every posting on
that topic
in the last eight or ten years in the comp.databases.ms-access and the
microsoft.public.access.* newsgroups.


I was not speaking of corruption due to disk failures; I was instead
referring to permitting garbage into the database due to the misuse of
auto-number primary keys.


An actual example I experience springs to mind - I have witnessed a
database where student projects were recorded via a schema of Project
Partners:{id:autonumber, RoleAerson, RoleBerson}, with PK(id).
None of the partnerships were aware of any "id" in the real world, and
simply submitted their partnership choices on paper to admin. A
clerical error resulted in 2/3 of the data being entered twice, which
left a lot of people flapping about the number of markers required
until the error was found. If the schema had used the natural {RoleA,
RoleB} key there would have been no issue.

But then for all I know, MS Access might allow duplicates anyhow....




However my knowledge is practical not theoretical.


I gained most of my knowledge the hard way as well, but that doesn't mean
that one shouldn't seek to understand and apply the theory.



Tony
--
Tony Toews, Microsoft Access MVP
* Please respond only in the newsgroups so that others can
read the entire thread of messages.
* Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
* Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/- Hide quoted text -


- Show quoted text -