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.
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.
Right, but that's the point of a GUID. Claiming no chance makes it sound like its distinct from other GUID generators in that way. I think the intended claim is "here is a scheme for roughly timestamp-ordered GUIDs", which makes it clear that the timestamp-ordering is the interesting part.
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.
Its an infinitesimally small chance. You'd need a mac collision, must be generated at the same time, and a uuid collision. Even at the largest scales (Google et all) the probability of that happening is effectively 0.
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...