This sounds like a case of premature optimization to me. We have plenty of databases using strings as Ids and they’re all more than fast enough for any of our purposes. And that’s with considerable volume going through.
I’ve never seen bad performance from string ids be an issue.
Have you never worked on a large distributed system before? There are good reasons not to use integer ids:
Generating ids on multiple machines is a hassle and requires careful configuration, which is not necessary when using uuid/cuid2 or something.
Ids have to be generated by the database, which is a huge degradation of overall system performance. If the application can generate the id, then the database insert is not a blocking operation anymore and you can just continue.
The performance difference is highly negligible, as it’s massively outweighed by fetching rows for example. With a proper database design, the difference is anywhere between 1-5%. If that makes the difference for your application, you’ve already made poor design decisions elsewhere that are far more important.
We use prefixed incrementing base63 uuids. It’s highly performant and we can generate it in the application, saving a lot of time in many processes because we don’t have to wait for the database anymore.
I’m sure doing int indexes over strings was once considered the gold standard but that’s not been true for years now. Yes, it’s slightly better for database performance. No, it’s not better overall for a slew of reasons, including system performance.
“what are you talking about? a hammer removes bolts just fine. i personally don’t have an issue with the tiny bit of extra elbow grease to wedge the claw around the bolt-head and twist; if anything, it’s saving me effort from having to use a wrench.”
can’t wait for the Clever Idea to offload costly string indices to an external source composed of redis box and some shitfuck app doing tf-idf after a Extensive Research into how to make string lookups be faster
they also stored this thing as a fucking string. looking up strings is costly.
This sounds like a case of premature optimization to me. We have plenty of databases using strings as Ids and they’re all more than fast enough for any of our purposes. And that’s with considerable volume going through.
I’ve never seen bad performance from string ids be an issue.
You haven’t seen shit then, simple as that.
so we’re calling “not doing pointless unnecessary work” premature optimization now? cool cool
Have you never worked on a large distributed system before? There are good reasons not to use integer ids:
We use prefixed incrementing base63 uuids. It’s highly performant and we can generate it in the application, saving a lot of time in many processes because we don’t have to wait for the database anymore.
I’m sure doing int indexes over strings was once considered the gold standard but that’s not been true for years now. Yes, it’s slightly better for database performance. No, it’s not better overall for a slew of reasons, including system performance.
ok shut up now
Making me learn how to do things the right way is premature optimization
“what are you talking about? a hammer removes bolts just fine. i personally don’t have an issue with the tiny bit of extra elbow grease to wedge the claw around the bolt-head and twist; if anything, it’s saving me effort from having to use a wrench.”
See https://programming.dev/comment/10515517 There’s good reasons to use something like a uuid over integers.
I really should reread that sometime
Also some Mickens
why is it always programming dot dev?
naw bro we’ve got indexes bro it’ll be fine bro
can’t wait for the Clever Idea to offload costly string indices to an external source composed of redis box and some shitfuck app doing tf-idf after a Extensive Research into how to make string lookups be faster