[AccessD] Primary Key Best Practices

Bruce,

While the DATA may in fact be badly formed (the table is not!), in real life
there are instances where the data is badly formed (there are duplicates)
and yet the data is still usable and still used.  

And while I admire all the "tuple talk", there are way more people in the
world (outside of academia) that understand tables, rows and fields.  I have
read the books, I understand the concepts, but I do not need to talk the
model talk and find it more useful not to.  And yes, I understand that there
are those that treasure their tuples.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen
Sent: Thursday, July 26, 2007 8:30 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Primary Key Best Practices

On Wednesday 25 July 2007 23:18, jwcolby wrote:
> Bruce,
>
> >Any table that does not have a natural primary key is not a pure 
> >dataset,
>
> ...
>
> No, Any table that does not have a natural primary key CANDIDATE is 
> not a pure dataset, ...
>
&< .....


Let me rephrase myself.

1) I'm not talking about indexes.
2) I'm not talking about Access/SQLServer/... tables

I was trying to indicate a "best practice".


If a tuple in a dataset cannot be uniquely identified by one (or possibly
more) natural keys (made up of one or more "natural data" fields of the
table), then the table is "badly formed" and further thought should be given
to the schema design before any indexes, based on real or surrogate data
should be considered.


I just thought the quick statement could be a BP "rule" that the OP could
have used.  I didn't mean to start DBWarLVI.

--
regards

Bruce
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com