|
|
Posted by Michael Fesser on 08/03/07 14:08
..oO(Sanders Kaufman)
>Actually, I find myself having to build stuff in MySQL that *might* end
>up on other DBMS's so relying on auto-unique stuff in MySQL isn't feasible.
Of course there are other - more portable - ways to create unique
numbers, i.e. sequences (some DBMS support them natively, in MySQL they
can be emulated).
>To keep my apps from breaking when they migrate like that, I've been
>using a UID function.
Not the best idea.
>By generating a UUID to use as your primary key, instead of the
>auto-increment thingy, YOU create the PK value as a "Universally Unique
>ID". (Now - I haven't travelled the universe, but my *faith* tells me
>it's a safe bet that I won't ever get a duplicate with one of these UUID
>functions.)
A UUID is not unique. It can be _considered_ unique, because a collision
is highly unlikely, but an AUTO_INCREMENT or a sequence _is_ unique.
>This has the *added* benefit of avoiding having to do TWO conversations
> with the DBMS - one to insert, and one to get the insert ID.
True, but on the other hand you're wasting a lot of space. It's even
more waste if the UUID PK is referenced from other tables. There might
also be performance issues with the InnoDB storage engine (from what
I've read).
>Instead,
>you just insert it with your own UUID as the PK. One shot, and the
>programmer is in control, not the DBMS.
>
>This becomes even *more* efficient if your DBMS and your HTTPd are not
>on the same server.
I don't consider that efficient. An AUTO_INCREMENT is efficient and
cheap. If it has to be portable, then using sequences can be the way.
Still more efficient than UUIDs.
Micha
Navigation:
[Reply to this message]
|