[AccessD] Primary Key Best Practices

>2. Has no duplicate rows; hence there is always a primary key.

So then, I should conclude that if there is no PK
then I should add one to make the table 'relational' and
-in practice- the fastest, most reliable way to
do that is to add an AUTONUMBER?

LOL!!!

Michael R. Mattys
MapPoint & Access Dev
www.mattysconsulting.com

----- Original Message ----- 
From: "Hale, Jim" <Jim.Hale at fleetpride.com>
To: "Access Developers discussion and problem solving" 
<accessd at databaseadvisors.com>
Sent: Thursday, July 26, 2007 9:51 AM
Subject: Re: [AccessD] Primary Key Best Practices


>
>
> <And I don't give a rat's patuty about relational theory, I care about
> what works.>
>
> LOL And how many times have we heard this from clients particularly when
> they are justifying bad design or databases that "work" but not really
> well. I think we have to grant Jim the point that the more we understand
> relational theory and its nuances the better we can make informed
> decisions in structuring designs. I am not a slave to relational theory
> but if I'm going to design away from dogma I want  my choice to be an
> informed one weighing the pros and cons. After all, these programs do
> purport to be relational so the more we understand where they succeeed
> or fail the better we become as developers. As a power user I began
> building "databases" long before I ever heard of relational theory. As I
> began learning the theory I understood how flawed and unscalable many of
> my constructs were. Today the databases I build don't religiously follow
> the gospel according to Codd but are better as I more closely understand
> and follow the relational model. Assuming that relational theory, at
> least in the abstract, is a logical internally consistent theory that
> works and is worth using, it is a "best practice" to implement the
> theory SUBJECT TO the constraints imposed by the hardware and software
> platforms being used.
>
> Jim Hale
>
>
> ***********************************************************************
> The information transmitted is intended solely for the individual or
> entity to which it is addressed and may contain confidential and/or
> privileged material. Any review, retransmission, dissemination or
> other use of or taking action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited.
> If you have received this email in error please contact the sender and
> delete the material from any computer. As a recipient of this email,
> you are responsible for screening its contents and the contents of any
> attachments for the presence of viruses. No liability is accepted for
> any damages caused by any virus transmitted by this email.
>
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com