RE: Roll Back dont roll back counters

From: "Michael Ansley (UK)" <Michael(dot)Ansley(at)intec-telecom-systems(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: RE: Roll Back dont roll back counters
Date: 2001-08-17 10:37:33
Message-ID: 7F124BC48D56D411812500D0B747251480F678@fileserver002.intecsystems.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

-----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(at)tincan(dot)org]
>> Sent: 16 August 2001 15:37
>> To: Martijn van Oosterhout
>> Cc: Ben-Nes Michael; pgsql-general(at)postgresql(dot)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(at)postgresql(dot)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-----

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2001-08-17 10:37:44 Re: slow update but have an index
Previous Message Martijn van Oosterhout 2001-08-17 10:12:55 Re: slow update but have an index