4 ms·
I can't tell if it's satire or not, but its a fun concept I thought UUIDs basically meant collisions would basically never happen though
by rtpg 11y ago
I can't tell if it's satire or not, but its a fun concept
I thought UUIDs basically meant collisions would basically never happen though
- s_kilk 11y ago> UUIDs But they're not artisanal. We need lovingly hand-crafted integers to go along with our double-tall-half-caff-extra-hot-mocha-lattes, nautical tattoos and neck scarves /s
- moron4hire 11y agoWhat other sort of scarves are there?
- tamana 11y agoHand scarves
- moron4hire 11y agoThat's called a towel.
- paulddraper 11y agoHead scarves
- moron4hire 11y agoThat's called a shawl.
- paulddraper 11y agoA shawl is worn over or around the shoulders. Sometimes that includes the head; sometimes is does not. Try an image search. Or watch Fiddle on the Roof :) https://youtu.be/7V2lxFWBqfI?t=2m49s https://youtu.be/7V2lxFWBqfI?t=2m49s
- BillinghamJ 11y agoIn theory. Very much depends on implementation though.
- creshal 11y agoVersion 4 UUIDs largely depend on your RNG's quality to avoid collisions.
- peteretep 11y agoUUIDs are out because the article says they're inefficient to store in the database vs integers, so one hopes it is indeed satire.
- dspillett 11y agoUUIDs are less efficient in databases though, so that isn't complete bollocks. * At 128 bits they are larger than the majority of integer types. If you are using them as keys for large data sets this might be a concern, especially if you are using them in a clustering key in SQL Server or similar because every non-clustered index entry would include the larger value too (a table with four extra indexes: that is 40 extra bytes per row if you have a UUID clustering key over a 64-bit integer, 60 extra compared to a 32 bit integer - if you have many millions or billions of rows that is worth considering). * Unless using some tweak such as SQL Server's sequential UUIDs they result in significant fragmentation (assuming a b+tree index structure with allocation and cleanup semantics similar to SQL Server, other DBs may manage things differently) due to their effective randomness, which wastes storage space & memory and can therefore impose greater IO and RAM load beyond that implied by the difference in size. UUIDs are great when you genuinely need them, but often an integer type is much more efficient so refrain from using them where you don't have a specific need to. The article and the services described are definitely satire though.
- michaelt 11y agoAt 128 bits And you'll probably end up handling them as 37-character strings, meaning you need 296 bits of space to store about 57 bits of data. And don't imagine you'll save any space by compressing it, as it's random and it'll compress terribly.
- dspillett 11y agoThat depends on your DB (and DBAs/developers). A good database has a specific UUID type which stores the value as packed as it can be in 16 bytes. Even without explicit support you could conceivably write a wrapper as part of your data access layer which packs them better (as 16 character strings assuming fixed 8-bits/character string types are truly 8-bit safe which is a fairly safe bet, or as a composite key of a number of integer columns). Of course that doesn't stop people storing them as text instead anyway. Worse: I maintain a legacy system (with not time/budget to refactor and regression test something this fundamental) where many are stored as two-bytes-per-character text (SQL Server's nchar type) so that is 74 bytes (58 wasted per UUID column per row per table/index). "Sequential" UUIDs like the special type implemented in MS SQL Server helps on the compression front (even when stored as proper binary types and not text) but it you are relying on compression for that you probably have other issues to deal with too...