[AccessD] Access and SQL Server

Hi Stuart --

<<<
I've never had a problem with an autonumber
>>>
"There is no free cheese in this world" you know :)

- replication could create subtle collision issues when autonumbers used -
and that would be another kind of collision from the one which could "arise
its ugly head" when natural PKs are used;
- memory overhead is another issue as Jim noted ("consistent data modelers"
do neglect it);
- ...

Isn't it time now to recapitulate constructively this discussion and to list
pedantically pros and cons of every approach? Anybody?

Thank you.

--
Shamil
 
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: 4 ????? 2011 ?. 6:47
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Access and SQL Server

If you chose to use an auto-increment pointer thingy as the primary key for
relationship purposes, then by definition  - it is a PK.

If Jim choses to use one real world value or a composite collection of  them
as the primary key for relationship purposes, then that too is a PK.

The  PK is  whatever *you* chose as the "primary" way to uniquely identify
records.

The choice between the two ways of doing so comes down to a personal
decision by the 
designer.   Neither way is "correct" or "the only way".

All I know is that in my experience, I've seen complications/problems caused
by using natural keys as the PK, I've never had a problem with an autonumber
so that's what I chose to use.

--
Stuart

On 3 Mar 2011 at 21:44, jwcolby wrote:

> AFAICT there is no debate other than what to call the auto-increment 
> pointer thingy.  As soon as we stop calling it a PK Jim seems to be 
> happy.
> 
> John W. Colby
> www.ColbyConsulting.com
> 
> On 3/3/2011 9:22 PM, Michael Mattys wrote:
> >
> > Education. Isn't that when we graduate into the rest of life?
> > I forget who polluted the world, was it the uneducated?
> >
> > Can we get back to the debate, please?
> >
> > Michael R Mattys
> > Business Process Developers
> > www.mattysconsulting.com
> --