Re: uuid type for postgres
От | mark@mark.mielke.cc |
---|---|
Тема | Re: uuid type for postgres |
Дата | |
Msg-id | 20050907011135.GA7369@mark.mielke.cc обсуждение исходный текст |
Ответ на | Re: uuid type for postgres (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: uuid type for postgres
|
Список | pgsql-hackers |
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 bindthem... http://mark.mielke.cc/
В списке pgsql-hackers по дате отправления: