[AccessD] Membership File Changes

Stuart McLachlan stuart at lexacorp.com.pg
Thu Mar 6 21:49:18 CST 2014


GUID?   I agree - very good for replication and/or multi remote data input locations.   Not just 
web based either - email, ftp,  offline tablets returned to base and data transfer via USB 
sticks from remote locations are all common scenarios.

As for cross tables,  I agree with you.  I differentiate between tables which store Entity and 
Link (Cross) data.   Surrogate PKs on the former are standard.  

In the latter case, they are only useful if the connection between entities has properties which 
should be stored in a child table.   But as soon as the link has such properties it becomes an 
Entity in its own right and I would use a SurrogatePK

-- 
Stuart

On 6 Mar 2014 at 20:56, Bill Benson wrote:

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



More information about the AccessD mailing list