UUID ve ULID Üretici
Rastgele ve zaman sıralı kimlikler, her türün neyde iyi neyde kötü olduğuyla.
UUID version 4
371a24aa-f0f1-4c73-a35b-c2bc784b3916 239c0d5c-25f7-4f1b-ae04-bdf850b52562 5b83e3fa-7e51-4359-acd2-73c0080ecea7 da9cb64d-be8b-4cd2-9243-c56f0d17a09a 1ef0f0ce-3e40-4223-a576-187edcf9a56f
Which one to use
- UUID version 4
-
The right default. Nothing about it can be read back: no time, no
machine, no order.
The wrong choice for a primary key in a large table. Consecutive rows land in unrelated places in the index, which makes inserts slower and the index larger than it needs to be. - UUID version 7
-
A version 4 with the clock in front. Sorts by creation time, so an
index grows at one end.
The same 36 characters and the same shape, so a column, a type and a library that hold a UUID hold this one without changing. The cost is that the creation time is now readable by anyone holding the identifier. - ULID
-
The same trade as version 7, decided before version 7 existed.
26 characters, no hyphens, case-insensitive.
Shorter, and easier to select with a double-click or read aloud. Against it: a community specification rather than an RFC, and a database with a native UUID type will not store it as one.
Generated on this server with the operating system's random source, sent once, and not stored. Reloading gives different ones; there is no way to get these back.