Stewart Smith wrote:
On Tue, Aug 12, 2008 at 10:43:16AM -0700, Robert Hodges wrote:
Some of the previous data type conversations reminded me of a question
that's been on my mind for a while. What do you think of dropping
auto-increment keys and replacing them completely with UUIDs?
Auto-incrementing is one of the banes of horizontal scaling so it seems
reasonable to substitute something that works across partitions and data
copies. Or at least to give application developers an opportunity to
suppress it.
Depends on how you use them... we do horizontal scaling in NDB and we
deal with auto inc fine (we prefetch batches of them). So if you were more
cloud like, there is no reason why you couldn't have something like this
plugged into the sql server.
But having UUIDs as an alternative is win :)
UUIDs are long and ugly, but they solve many problems with
sequences/timestamps/generators:
1. They don't appear to be sequential, so there aren't holes to upset
beancounters
2. They don't appear to be sequential, so developers don't make
unwarranted assumptions
3. They can't be reset, protecting dumb users from theirselves
4. They work in clusters and clouds without hassle
5. There is no expectation that they will be reused after a rollback.
6. A UUID is known unique, so uniqueness check can be skipped for
unique indexes
7. UUID generation doesn't need inter-thread synchronization
8. Generated UUIDs don't need to be logged and recovered
A better way to handle automatic timestamps is
when timestamp initial value 'now'
Among the serious problems with MySQL, er, quaint semantics for
timestamps is the amount of coffee snorted through database developers
noses when they figure out "that was the way it was supposed to work."
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
