Martijn van Oosterhout wrote:
> Well, it kinda sucks for joining because comparing strings may take
> tens to hundreds of times as long as compairng integers. It's not just
> byte-wise comparison but you have to be locale sensetive about it.
>
> My main problem with using any kind of string as "natural key" is that
> once you start passing it around you have worry about the encoding of
> said string and when it goes a round-trip to a client, will what you
> get back still be the same? If you can guarentee ASCII you might be ok,
> but otherwise... Integers have none of these issues.
That sounds like there would be a purpose for a locale-less type of
string, as ugly as that is.
That's not a feature request, just something to digest ;)
>> Having two keys, a primary_key of int4 and a unique key of varchar(128)
>> would be very ugly on INSERT/DELETE/UPDATE queries because of the index
>> overhead.
>
> In general my tables are queried several orders of magnitude more often
> than they are updated, so index update cost isn't all that relevent.
Indeed. Basically if expensive calculations can be pre-calculated I tend
to move them into triggers that store the pre-calculated result. Usually
there's only a handfull of people modifying data, while there are many
people requesting it.
Regards,
--
Alban Hertroys
alban@magproductions.nl
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World //
