FW: [HACKERS] Surrogate keys (Was: enums)

2006-01-18 Thread Jim Nasby
Ooops, fat-finger'd -hackers... -Original Message- Adding -hackers back to the list. From: Leandro Guimarães Faria Corcete Dutra Em Seg, 2006-01-16 às 12:52 -0600, Jim C. Nasby escreveu: On Sat, Jan 14, 2006 at 07:28:21PM +0900, Michael Glaesemann wrote: For UPDATEs and

Re: FW: [HACKERS] Surrogate keys (Was: enums)

2006-01-18 Thread Jim C. Nasby
Comparing two ints is much, much faster than comparing two text fields. For a small number of comparisons, it doesn't matter. When you're joining tables together, it's a different story. That is where data independence would come handy... like a better enum, with possreps and hidden

Re: FW: [HACKERS] Surrogate keys (Was: enums)

2006-01-18 Thread Leandro Guimarães Faria Corcete Dutra
Em Qua, 2006-01-18 às 17:22 -0600, Jim C. Nasby escreveu: Forgive me my ignorance, but are ints inherently faster to compare than strings, or is it just an implementation detail? Ideally, if this is so a fully data-independent system would create a hash behind the back of user in order

Re: FW: [HACKERS] Surrogate keys (Was: enums)

2006-01-18 Thread Dann Corbit
PROTECTED] [mailto:pgsql-hackers- [EMAIL PROTECTED] On Behalf Of Leandro Guimarães Faria Corcete Dutra Sent: Wednesday, January 18, 2006 4:31 PM To: Jim C. Nasby Cc: pgsql-hackers@postgresql.org Subject: Re: FW: [HACKERS] Surrogate keys (Was: enums) Em Qua, 2006-01-18 às 17:22 -0600, Jim C

Re: FW: [HACKERS] Surrogate keys (Was: enums)

2006-01-18 Thread Josh Berkus
Dann, The primary key should be immutable, meaning that its value should not be changed during the course of normal operations of the database. Why? I don't find this statement to be self-evident. Why would we have ON UPDATE CASCADE if keys didn't change sometimes? At any rate, the use