On Tue, 5 May 2020 at 07:38, Niklas Keller <m...@kelunik.com> wrote: > Rowan Tommins <rowan.coll...@gmail.com> schrieb am Mo., 4. Mai 2020, > 10:59: > > Although the name sounds similar, I don't think UUID would be a good > > replacement for uniqid(). In my experience, it's used for things like > > generating ID attributes for HTML elements, or suffixes for table names, > or > > even file names; applications that really just need a few alphanumeric > > characters that are different each time. > > > > Seems like UUIDs would be a good fit for all of these. >
For file names, absolutely. In many cases they have to be unique across all processes, and that's important. For the others I say a UUID is only a good replacement if taking a substring of a UUID is going to be unique. Take HTML element IDs. My experience is UUIDs (random data) doesn't compress well, and so shorter unique strings are preferable (also for reading the HTMl when debugging). The number of elements you're adding IDs to matters: if you add 10 then the UUID overhead is negligible; if you're adding to thousands it's different. For table name suffixes (if needed), the maximum length of a table name is 64 characters in MySQL. It's easier to cope with all systems if the table name pre-suffix can be more than 28 characters (27 if you put a separator between the table name and the suffix) For these reasons, I support adding a nice way to generate semi-unique data, preferably of user-defined length, and that doesn't have the drawbacks of uniqid(). And deprecating uniqid(). Peter
