31–40 of 77 posts
Earlier quoted context omitted.
Or just use ints and encrypt them when you want to return them to the user. https://sqids.org/
NB: may be more accurate to call this hashing, versus encryption
Thanks, chatgpt.
Did the article provide any reason for ULID over UUID? - it’s slightly more complex than UUID, but not enough to be a problem - it’s sortable (in time?) which UUID can also be (but usually recommended not to be) - it can produce slightly more ids per second, but not enough to make a difference. So, it’s a tie, a tie and a tie. Why would you switch?
> I am not going to cover all the reasons why Ulid is better, but in the end, it's up to your personal preference.
I am not going to cover all the reasons why Ulid is better"
Well, this article was definitely worth it /s
Earlier quoted context omitted.
> your database is spending all it's time shuffling everything around to insert your new rows in the middle of everything Is it? The order of data on disk tends to be the insertion order. What might get shuffled around is the index for the primary key, but indexes can handle that quite well.
And the answer is "depends on the database tech". Here are some nice benchmarks: https://www.toomanyafterthoughts.com/uuids-are-bad-for-datab... I learned the lexically-sortable-id trick from wizened DBAs in the 90s. It's an old trick. I've applied it myself to speed things up and have used both the ULID types described in the article and UUIDv7 etc. I even advocate using UUID7 on BigQuery where there are no indexes.…
Did the article provide any reason for ULID over UUID? - it’s slightly more complex than UUID, but not enough to be a problem - it’s sortable (in time?) which UUID can also be (but usually recommended not to be) - it can produce slightly more ids per second, but not enough to make a difference. So, it’s a tie, a tie and a tie. Why would you switch?
If your team hasn't engineered in monotonically increasing distributed clocks, the results of sorting are only partly correct. I'd rather not promote an option we can't rely on.
Eg messaging, tweets etc: if two messages are sent at pretty much the same time, it does not matter which order they show in.
Thanks, chatgpt.
Yeah that code example is odd to say the least.
> f4b6a3: a meaningless random package name
...well, I guess that's one way to name your library!
At this point I think that ideal setup is to use numerical id for primary and foreign keys and maintaining a separate uuid field for everything else. The reason being that index size matters a lot (for caches and other things) and index size depends on underlying field size, obviously. Whether to use UUID or ULID is depends on tooling. While it's not hard to write ascending UUID generator and I did it myself few time…
would you still keep a uniqueness constraint on the uuid/ulid column?