[AccessD] Primary Key Best Practices

Any database made up of a single table would not require a PK. 


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 John Bartow
Sent: Wednesday, July 25, 2007 4:27 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Primary Key Best Practices

Good point. And one I glossed over while postulating my responses.

I can't remember ever having a table without a PK in any RDBMS. I can't even
imagine what data would be stored in an RDBMS that didn't need a PK.

This is what is so befuddling to me when it comes to Outlook's contacts...

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart
Sent: Wednesday, July 25, 2007 2:31 PM

At 12:00 PM 7/25/2007, you wrote:
>From: "jwcolby" <jwcolby at colbyconsulting.com>

Whooo, there cowboy. Without a PK, how are you going to identify rows for
updates and delets?  Good design REQUIRES a primary key of some kind even if
it is a composite key. Try updating a SQL Server table linked to MS Access
that does not have a primary key. It will not let you make any change to it
at all.

>AND... from the perspective of the child, a FK is nothing but a pointer.
>Does a table HAVE TO HAVE a PK at all?  Not if it has no children.  
>Ergo, what matters from the child's perspective is what the PK is all 
>about, and that is simply a POINTER back to the parent.  AND... Since a 
>surrogate key functions as a PK, then... A PK must be nothing but a
pointer...

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