RE: Roll Back dont roll back counters

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Um, no, primary keys should not always be opaque.  Technical primary
keys should always be opaque.  Relational modelling has been built to
exploit primary keys actually being the business key, to create
proper identifying relationships.  Using technical PKs undermines
this, although often this is offset by carrying large primary keys
through to child tables.  For most simple to moderately complex
tables, I prefer using the business key as the primary key, and only
using a technical key when it's really (REALLY) warranted.  How do I
differentiate?  Well, common sense is probably the best.  'Address'
gets a technical ID, because it's business key would be cumbersome,
the same with 'person'.  But 'Network Operator' already has a five
character business key, and that's adequate without a technical key,
as is the seven character 'Tier' business key, and the twenty
character 'Point of Interconnect' key, even though they could all
feasibly take a technical ID.

And when you're trying to read an ER model, technical keys are a pain
in the butt, because it becomes incredibly difficult to read meaning
into the model.  With matching business and primary keys, reading an
ER model is a doddle.  Almost...

MikeA

>> -----Original Message-----
>> From: Roderick A. Anderson [mailto:raanders@tincan.org]
>> Sent: 16 August 2001 15:37
>> To: Martijn van Oosterhout
>> Cc: Ben-Nes Michael; pgsql-general@postgresql.org
>> Subject: Re: [GENERAL] Roll Back dont roll back counters
>>
>>
>> On Thu, 16 Aug 2001, Martijn van Oosterhout wrote:
>>
>> > You can tell the order anyway. The order doesn't change,
>> it's only that
>> > there may be numbers missing,
>>
>> Please note the message from "Michael Ansley (UK)".  If two of
>> more connections get a cache from a sequence and the inserts are
>> 'sporatic'
>> then there will be a difference in the sequence number and the
>> insert order.
>>
>> > Primarys keys should be opaque. Any meaning read into them
>> is entirely
>> > coincidental.
>>
>> I agree.
>>
>>
>> Rod
>> --
>>
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 3: if posting/reading through Usenet, please send an
>> appropriate subscribe-nomail command to majordomo@postgresql.org
>> so that your message can get through to the mailing list cleanly
>>

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBO3zzwHympNV/C086EQLiCgCdHWBEvPlk+ueJUwMPm8PBdnuHUbMAoMt7
J6HkkM3TYof9ehs4S0pGYUwu
=pASp
-----END PGP SIGNATURE-----

_________________________________________________________________________
This e-mail and any attachments are confidential and may also be privileged and/or copyright
material of Intec Telecom Systems PLC (or its affiliated companies). If you are not an
intended or authorised recipient of this e-mail or have received it in error, please delete
it immediately and notify the sender by e-mail. In such a case, reading, reproducing,
printing or further dissemination of this e-mail is strictly prohibited and may be unlawful.
Intec Telecom Systems PLC. does not represent or warrant that an attachment hereto is free
from computer viruses or other defects. The opinions expressed in this e-mail and any
attachments may be those of the author and are not necessarily those of Intec Telecom
Systems PLC.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
__________________________________________________________________________