<div dir="ltr">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.<br>
<br>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?<br>
<br>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? <br>
<br><div class="gmail_quote">On Tue, Aug 12, 2008 at 8:37 AM, Ethan Fremen <span dir="ltr"><<a href="mailto:ethan@acquia.com">ethan@acquia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Aug 11, 2008, at 7:20 AM, Victor Kane wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
OK, but please all take into account that it is not necessarily the<br>
best thing to tie the creation of the UUID to the database at all.<br>
</blockquote>
<br></div>
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.<br><font color="#888888">
<br>
~ethan fremen<br>
</font></blockquote></div><br></div>