-----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.
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-----
