3 ms·
As a Microsoft SQL user (not everyone can choose their DB..), UUIDv7 has the issue that people will (understandably, but ignorantly) store it in "uniqueidentifi
by dagss 3y ago
As a Microsoft SQL user (not everyone can choose their DB..), UUIDv7 has the issue that people will (understandably, but ignorantly) store it in "uniqueidentifier", which shuffles bytes around and are no longer sorted on time... ..
There is even a specific Microsoft SQL-time-ordererd UUID format which is sorted after byte shuffling..
We store ULID in binary(16). Works nicely. Only difference from UUIDv7 is the version bits..
- djbusby 3y agoCouldn't you put UUIDv7 in byte(16) and get the same feature? I found today a PHP UUID library that does one they call UUIDv8 which has more time (like ULID)
- dagss 3y agoYes, one could. The problem is most programmers who are not aware of this (probably most), will see the UUID and make assumptions that uniqueidentifier type is the most suited one. They are less likely to take a ULID and store it in binary(16). (Might store it in char(26), which is less storage efficient but is still sorted.) Apart from that I happen to LIKE the fact that I can very quickly see the difference between a random identifier and a sorted identifier, they have quite different characteristics after all.. Although I guess people might eventually get used to the initial bytes being 0 on UUIDv7, or just learn to recognize the version bytes.. On that topic, why are the 8 fixed bits of a UUID not concentrated on the same byte. Perhaps the first one. Huge mistake..