From: mark@mark.mielke.cc
To: Josh Berkus <josh@agliodbs.com>
Cc: Bob Ippolito <bob@redivi.com>
Cc: jonah.harris@gmail.com, pgsql-hackers@postgresql.org, nathan wagner <nw@hydaspes.if.org>
Subject: Re: uuid type for postgres
Date: Tue, 6 Sep 2005 21:11:35 -0400
Message-ID: <20050907011135.GA7369@mark.mielke.cc> (raw)
In-Reply-To: <200509061802.51089.josh@agliodbs.com>
References: <20050906135057.GA24136@granicus.if.org>
<36e6829205090612575b954f38@mail.gmail.com>
<3F60E55D-B558-4929-B614-C230EACFF473@redivi.com>
<200509061802.51089.josh@agliodbs.com>
On Tue, Sep 06, 2005 at 06:02:50PM -0700, Josh Berkus wrote:
> However, Mark went on to suggest that we should recommend UUID over SERIAL
> in the docs, and that we could consider dropping SERIAL entirely in favor
> of UUID:
> ---quoth Mark------------------
> I suggest that UUID be recommended in place of SERIAL for certain
> classes of applications, and that it therefore belongs in the core.
> UUID and SERIAL can be used together (although, once you have a
> UUID, it may not be useful to also have a SERIAL).
> ---------------------------------
> This was what I objected to; I believe that the use-case for UUIDs is
> actually quite narrow and assert that it's a very bad idea to promote them
> to most users.
Ahhh... :-)
I intended the word 'certain' to be emphasized in some way, rather
than dropped. There are genuine uses for UUIDs. I didn't intend for
everybody to pull out their database definitions and change them all to
use UUID instead of SERIAL.
Although - I don't think really bad things would happen if people did.
They would simply be making a non-optimal choice (abusing the type?).
Certainly nothing they weren't capable of before this particular
capability were to arrive. :-)
> I have a "problem" with SERIAL abuse, too. In general, new DB designers
> have come to increasingly believe that surrogate keys (SERIALs, UUIDs,
> hash ids etc.) are an intrinsic part of the relational model and a
> requirement for all tables. Terrible database designs have resulted,
> chock full of tables which lack real keys and cannot be normalized.
> UUIDs tend to encourage this sort of behavior even more than SERIALs, not
> because of any intrinsic quality in the data type, but because much of the
> literature on the subject treats them like some kind of "universal object
> identifier" and not distinguishing servers, relations, or real keys.
> To repeat, though, this isn't a reason to keep them out of core, but it
> *is* a reason not to throw them at newbies as the holy grail of row
> identifiers.
I agree. Although I lost it on the "cannot be normalized". I'm assuming
there are designs you have seen much worse than the ones I have seen. :-)
> For my part, I generally push implementing the UUID concept in a better way
> that keeps server, table, and surrogate keys atomic (and thus more useful
> and easier to debug).
My eyes are glazing over a bit on this last one. Atomic?
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: mark@mark.mielke.cc, josh@agliodbs.com, bob@redivi.com, nw@hydaspes.if.org
Subject: Re: uuid type for postgres
In-Reply-To: <20050907011135.GA7369@mark.mielke.cc>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox