[AccessD] Membership File Changes

Autonumbering of visible/meaningful Invoice Numbers is definitely a no-no.  It *will* result in 
gaps.  

Application generated Invoice Numbers according to business rules combiined with 
autonumbering of a surrogate PK for each invoice which end users never see is a definite 
"yes-yes"  :-)

-- 
Stuart


On 6 Mar 2014 at 20:47, 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
> -- 
> 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
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>