On 02/04/13 06:35, jesusthefrog wrote: > On the topic of 'natural' versus 'synthetic' primary keys, I am > generally in the camp that an extra ID field won't cost you too much, > and while one may not need it for a simple table (i.e. id, name) one > might add any number of columns later, and you'll be glad to have it. Definitely, a lookup table can be extended to hold all kinds of statistics and translations on a "tag". I didn't look too deeply into the actual usage (not sure if any real examples where given). But ON UPDATE CASCADE if not a feature I would recommend in this context (referencing a PK) if at all. > I am, however, against using sequences (or serial integers in Postgres) > for reasons of scaling and replication across multiple copies of a > database running on different servers. > > My preferred method is to give every table an ID column of UUID type and > generate a UUID using the uuid-ossp contrib module. This also prevents > someone not familiar with the database design from using an ID somewhere > they should not (as is possible with natural PKs) or treating the ID as > an integer, not an identifier (as is all too common with serial integers). > It was instagrams own implementation, but mentions twitters "Snowflake". Interesting read still only requires a bigint. http://goo.gl/gRlXC IMO uuid is convenient but large and for all that data it doesn't hold anything useful. I have been tempted though. Jules. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
