On Sun, Jan 10, 2010 at 4:24 PM, Roger Binns <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Chris Anderson wrote: >> I'm not feeling super-strong about this. However, making the default >> sequential seems like it will preempt a lot of the problems people >> tend to show up asking about. >
If we think that speed and size are more important than randomness, we should continue to refine uuid generators. Roger, if you can make a short sequential that'd be neat. > There are several issues conflated together: > > - - When doing inserts, sorted ids are faster > > - - The resulting size of the db file is the size of the docs plus a multiple > of the _id size (and probably an exponential of the size) > > - - Sequential ids give small _id > > - - Random ids give large _id > > - - Sequentials will clash between different dbs (consider replication, > multiple instances etc). They'll also lead people to rely on this > functionality as though it was like a SQL primary key > > - - Random ids won't clash and better illustrate how CouchDB really works > >> I think the info-leakage argument is overblown > > It does make URLs easy to guess like many ecommerce sites that didn't > validate when showing you an invoice - you added one to the numeric id in > the URL and got to see someone elses. > > I would far prefer the size of the db file and the size of the _id link > being addressed. Because the _id size can cause the db file to get so big, > I/O etc is a lot slower mainly because there is just so much more file to > deal with! (In my original posting I had a db go from 21GB to 4GB by > reducings ids from 16 bytes to 4 bytes.) > > Roger > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAktKb8AACgkQmOOfHg372QRb0ACfRWu1TUOs3twwmOGgAUOwhLfx > FJkAoKgnkWnPayPtPqMfk3/AxOj2xaMx > =V7Zq > -----END PGP SIGNATURE----- > > -- Chris Anderson http://jchrisa.net http://couch.io
