[mumrah]

If you want sequential IDs with no chance of collisions, read up on "flake" IDs

* https://blog.twitter.com/2010/announcing-snowflake

* http://engineering.custommade.com/simpleflake-distributed-id...

* http://boundary.com/blog/2012/01/12/flake-a-decentralized-k-...

* https://github.com/mumrah/flake-java

[pauldbau]

For .NET / SQL Server people, check out GuidCombs if you want better Primary Key performance. These are a great way of making GUIDs sequential for database use, giving indexing performance close to ints on SQL Server.

I imagine this approach could also work on Postgres and other dbs that have made GUID/UUIDs a first class data type. You'd just have to understand how that database applies its indexing algorithm.

Description of the GuidComb approach here: http://www.informit.com/articles/article.asp?p=25862

GuidComb implementation in C# (from NHibernate core) here: https://github.com/nhibernate/nhibernate-core/blob/master/sr...

[thedufer]

"no chance of collisions" can't be applicable to any finite-length ID. Low chance, perhaps.

That said, this appears to be exactly the scheme MongoDB uses (except Mongo IDs are 96 bits).

[JoeAltmaier]

Ok, Less likely than the chance your computer will spontaneously catch fire while running your code. Less likely than the chance the sun will emit a colossal solar flare and engulf the earth in a firey death.

[Goopplesoft]

Actually it can. As long as they aren't randomly generated. UUID4s are random, lots of them including the mongodb use a timestamp/mac address as the first n bits of the guid. Not sure whether they have "no chance of collisions" but it is very possible.