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@xxxxxxxxxxxxxxxxx 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 //
