[AccessD] Primary Key Best Practices

At 12:00 PM 7/25/2007, you wrote:
>Date: Wed, 25 Jul 2007 11:19:00 -0400
>From: "jwcolby" <jwcolby at colbyconsulting.com>
>Subject: Re: [AccessD] Primary Key Best Practices
>To: "'Access Developers discussion and problem solving'"
>         <accessd at databaseadvisors.com>
>Message-ID: <20070725151912.941B1BCEA at smtp-auth.no-ip.com>
>Content-Type: text/plain;       charset="us-ascii"

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...