[AccessD] Membership File Changes

ROTFL.  There was never any autonumbering because they didn't understand the concept.  They aren't 
"either / or".  The PK / FK should NEVER be seen by the user.  EVER.  They are nothing more than a 
convenient construct for generating pointers between records in tables.

I have been doing databases for 20 years and I have never seen a table (other than replication 
issues) where an autonumber didn't work for that.

John W. Colby

Reality is what refuses to go away
when you do not believe in it

On 3/6/2014 10:47 PM, Jim Lawrence wrote:
> Just to add a little more...
>
> Many of the systems I worked on were POS systems which all required a accounting component. Therefore no records could be deleted...they were just set to non-display and the invoices had to numbered in sequential order...so the numbering was supplied under program control so there never was any auto-numbering.
>
> Jim
>
> ----- Original Message -----
> From: "Bill Benson" <bensonforums at gmail.com>
> To: "Access Developers discussion and problem solving" <accessd at databaseadvisors.com>
> Sent: Thursday, 6 March, 2014 5:56:27 PM
> Subject: Re: [AccessD] Membership File Changes
>
> Can't resist jumping in here, maybe I will learn something... My own
> experience is too limited to claim to be an expert in this matter. If you
> are going to jump down my throat, please take your boots off first.
>
> AFAIK, GUID is used for only two reasons:  (1) When a relational database is
> distributed in more than one location via replication and (2) when some
> transactions are created client-side then handed back to the server via web
> methods. I would expect GUID to be relatively poor, but in some situations
> reliable whereas getting the next higher number through autonumber (or a
> sequence on the database) may not be so.
>
> As for multi-field PKs, I think where they make sense is in cross tables?
>
> If I have a subscription that consists of a Customer and a Publication, I
> can usually prevent duplicate subscriptions by keeping track only of
> CustomerID and PublicationID. If John Jones has ordered The Economist, then
> I would keep a composite ID in the Subscriptions table of FKCustomerID and
> FKPublicationID.
>
> Of course, this begs the question what happens when John Jones orders The
> Economist for his three sisters. But in that more complex situation, it
> would just change the FKCustomerID to instead be FKRecipientID and we arrive
> at the same deduction:  we really do not need a SubscriptionID and it serves
> no purpose either in terms of speeding up the database, nor giving us any
> descriptive information.
>
> For those who contend our database acts any faster with it, I would ask, how
> so?
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David McAfee
> Sent: Thursday, March 06, 2014 8:02 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Membership File Changes
>
> <snip>
> This strategy is not without detractors however, mostly "old timers" from
> databases where multi-field PKs were ALWAYS used. Mostly they try to argue
> that it is possible to just read the PK down in the child / grandchild /
> great grandchild etc. simply by looking at the data in the multi-field PK,
> which "saves your bacon" when orphans creep in and so forth.  Additionally
> the "values" can often be pulled for reporting and the like, without
> requiring joins back up the chain.  Both are true, but not (IMO) make up
> for the overhead and headaches that multi-field PKs bring with them.
> </snip>
>
> John, I was recently called an old timer because I insisted on using
> autonumber integer PK for some of our new designs.
> The young whipper snapper said that's the "old way" of doing things, and is
> very anal about using GUIDS and multi-field PKs.
>
> I know GUIDs have their place, but he just doesn't get it. I love how my
> stuff runs so much faster, even with joins. :)
>
> D


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com