[AccessD] Primary Key Best Practices

Charlotte Foust cfoust at infostatsystems.com
Wed Jul 25 16:50:15 CDT 2007


You're picking nits, John.  You'd still need an identity field to edit
it in SQL Server.  If the unique key exists, you have a functional PK,
whether you call it that or not. 

Charlotte Foust 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, July 25, 2007 2:47 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [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

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




More information about the AccessD mailing list