UUID ve ULID Üretici

Rastgele ve zaman sıralı kimlikler, her türün neyde iyi neyde kötü olduğuyla.

UUID version 4

b4d16f23-ed34-448a-aa56-58762057126f
ef389bd1-1ec0-4208-932a-3b85ecacbc77
56ae8460-7448-4469-94db-94de132c01ac
9d2cdc03-b023-4816-8d91-fad72215f3c9
e148513f-c7b7-482b-a087-b0fa45e961ae

Random. 122 bits of it, and nothing else.

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.