[development] Unique/Random IDs and drupal

Darrel O'Pry darrel.opry at gmail.com
Tue Aug 12 14:13:16 UTC 2008


I'm all in favor of supporting 64bit ints in the database, whether we're
going for UUID's or not. I'm personally experimenting with 64bit timestamps
instead of using DateTime strings for storing dates. It is silly to not use
it because "Noone could concievably use that many ID's in the near future."
Platform native word length is a valid argument.

UUIDs are 128bit... so I don't see how 64bit values helps you implement
UUIDs either, If it's 64bits it's not a UUID per spec it's something else.
You probably need a char(36) and hexadecimal representation if you wish to
store UUIDs in a single column unless, or you have a plan for reducing the
significant data which needs to be stored in the index to 64bits, or you
plan to spread the UUID over two integer indexes?

I don't quite follow how the sharding is intended to be implemented. I'm
more curious about your plans for that. I've read up on how flickr does
their user centric sharding, but how do you see the concept being mapped to
Drupal?

On Tue, Aug 12, 2008 at 8:37 AM, Ethan Fremen <ethan at acquia.com> wrote:

> On Aug 11, 2008, at 7:20 AM, Victor Kane wrote:
>
>  OK, but please all take into account that it is not necessarily the
>> best thing to tie the creation of the UUID to the database at all.
>>
>
> 100% agreed. Right now I'm most strongly in favor of using the OSSP UUID
> library (aka php5-uuid in debian/ubuntu), which is, btw, *much* faster than
> the DIY random-64-bit identifiers I tried.
>
> ~ethan fremen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080812/9038ab92/attachment.htm 


More information about the development mailing list