6 ms·
If you want unique identifiers, use version 4 (random) UUIDs. Problem solved. The probability of a collision is roughly the same as the probability of a fully
by p-e-w 3y ago
If you want unique identifiers, use version 4 (random) UUIDs. Problem solved.
The probability of a collision is roughly the same as the probability of a fully grown dinosaur spontaneously manifesting in your bedroom due to quantum fluctuations.
- jraph 3y agoI will take my chance :-) More seriously, If you can use them, good old increments are probably best. They are fast and cheap. Especially in a database. They can have privacy/security issues (you could guess things by the values of ids of stuff). UUIDs are better in those case or when you deal with a distributed system.
- p-e-w 3y agoUnless the RNG itself is the problem, there's no reason not to. All kinds of civilization-ending catastrophes are vastly more likely than a collision in a space of size 2^122.
- p-e-w 3y ago> They can have privacy/security issues (you could guess things by the values of ids of stuff). Push them through a secure hash function, and that problem is solved too (assuming you can keep the base counter private).
- cacheyourdreams 3y agoIf you're going to do that then you might as well just use UUID, since you effectively reintroduce the negative aspects of that (infinitesimally miniscule chance of collisions, computation involved in the calculation, etc.)
- p-e-w 3y agoThe difference is that you can still use sequential IDs internally, while exposing hashed IDs to the outside. This protects your database from collisions under all circumstances, while in the absolute worst case, a single user might experience bugs because two external IDs collide.
- cacheyourdreams 3y agoYes, I tend to like this philosophy in database design, of internal sequential ids which are used for joins between tables etc. and an exposed "external reference". But I typically would use a UUID for my external reference rather than a hash of the internal id.
- newaccount74 3y agoDoesn't that just add a whole lot of unnecessary complexity? If elements have multiple IDs, one of which should not be leaked to the outside, that's just asking for trouble in my opinion. Is generating UUIDv4 or UUIDv7 really too much effort? I'd assume that writing the row to the database takes longer than generating the UUID.
- iforgotpassword 3y agoIt also means once your hash function leaks for whatever reason or gets brute forced because of whatever weird weakness in your system, it's game over and everybody will forever be able to predict any future ids, guess neighboring ids, etc., unless you're willing to change the hash and invalidate all links to any content on your site. If I'm in a scenario where I think I need consecutive ids internally and random ones externally, I'll just have two fields in my tables.
- jstanley 3y agoYou need 2 fields anyway, unless you want to have to brute force your hash function when you need to invert it.
- wongarsu 3y agoStore just the sequential id, compute the hash on the edge. This keeps your database simple and performant, and pushes complexity and work to the backend servers. This can be nice because developers are typically more at home at that layer, and scaling the backend can be a lot easier than scaling your database. But it also comes with the downsides listed in this thread.
- marcosdumay 3y agoHum, no. You can easily hash numbers from 1 up to the value you see and guess the next value. If you want a secure identifier, make a random 64 or 128 bits number (a UUID type 4). And do not use this number as an internal identifier, because identifiers performance is all about predictability and low entropy.
- gnulinux 3y agoIf you use a robust salt, such a randomly generated long salt, attacker won't be able to guess the next hash.
- fluoridation 3y agoA block cipher is better, as it's guaranteed to not have collisions.
- enyone 3y agothe dinosaur is now on my bed, what next?
- MattPalmer1086 3y agoClose the door and immediately switch to v5.
- quickthrower2 3y agoEnjoy the non heat-death of the universe
- lyu07282 3y agoI would just call Randall Munroe, he will know what to do
- deleted 3y ago[deleted]
- fendy3002 3y agobut is it higher or lower if the dinosaur is not fully grown?
- zzo38computer 3y agoI would guess slightly higher probability for a not fully grown dinosaur because the mass will be less, I think.
- dtech 3y agov7 looks nicer since it solves v4's locality issue and you're still a gazillion times more likely to win the lottery than generate a collision.
- littlestymaar 3y ago> The probability of a collision is roughly the same as the probability of a fully grown dinosaur spontaneously manifesting in your bedroom due to quantum fluctuations. I'd love to see the math for the probability of the second option.
- beefield 3y agoKnowing nothing about UUID v4 generation, I have likely a stupid question. What makes you so confident that all implementations and their entropy sources are flawless enough to make actual collision probability close enough to theory?
- Thiez 3y agoWhat makes us so confident that our database implements ACID correctly, the RAM stores bins correctly, and the disk drivers store the data correctly? In the end we have to make some assumptions about the correctness of (some of the) components.
- tjoff 3y agoWe are not confident in any of that. Which is why we mitigate it with checksums, ECC etc. So depending on the consequences you might opt to reduce the risk or help mitigate the consequences. To just state that it is about as likely as my coffee maker being a portal to the future isn't very helpful. Poor entropy sources or bugs are not uncommon.
- amelius 3y ago> The probability of a collision is roughly the same as the probability of a fully grown dinosaur spontaneously manifesting in your bedroom due to quantum fluctuations. But now the probability of bad things happening increased by about a factor of two, which is not acceptable.
- notpushkin 3y agoI don't see how sudden dinosaur appearance is a bad thing.
- zzo38computer 3y agoHow will you sleep? (Anyways, comparing the probabilities does not necessarily mean that the things being compared are both bad or both good.)
- amelius 3y agoPerhaps it is made of anti-matter.