4 ms·

I really hate this trend away from basic IDs. I feel like it's driven by folks who've never actually worked in the real world. I got account paperwork recently

I really hate this trend away from basic IDs. I feel like it's driven by folks who've never actually worked in the real world. I got account paperwork recently where the company ID account ID and invoice ID were all uuids. 100% this company if I call them will not use this BS to lookup my account and will instead use something easier try to guess like a company phone number. I also had to do some support tickets recently and because of the issues copying uuids from the screen they insisted on screenshots that included the url bar showing uuid. 100% trying to tell them the ID over try the phone or even rekey would run into issues. Give me back my sequential invoice ids!

brightball 4y ago
This is a very worthwhile point. You definitely need to prepare for readability if these ids will be customer facing.
- craigkerstiens 4y ago
  While not a perfect solution to it, we use UUIDs throughout our application as IDs. But when we expose them in URLs or other places provide them as an encoded id (https://docs.crunchybridge.com/api-concepts/eid/ https://docs.crunchybridge.com/api-concepts/eid/). It at least makes them a little more compact, easier to copy/paste than UUIDs, and generally a cleaner look.
mytailorisrich 4y ago
As it happens in at least some jurisdictions invoice numbers have to be sequential by law.
- Scarbutt 4y ago
  That's orthogonal to having a programatic ID for them
victor106 4y ago
Are sequential id’s a security risk? In one of our systems we’ve seen customer guess at other accounts by just incrementing the sequence. The rule of thumb I used to use is if an Id is going to be used for lookups or being exposed externally use uuid otherwise us sequential. The hard thing about the above rule is that it’s hard to tell when you are designing the db if the id will be used externally/for lookups or not. Requirements change later.
- hnarn 4y ago
  "Protecting" records by making IDs hard-to-guess just seems like putting the responsibility in the wrong place. If you're so worried about people getting their hands on the wrong records, I'd be more worried about your lack of trust in the application that queries that database in the first place: remember, even if you do make the IDs hard to guess, your "untrusted application" might at some point decide to simply leak the entire table instead. There are much better solutions for this, like server-side prepared queries that do not simply return on an ID but rather as the result of a join, or just proper security practices in general, rather than reactively making something that was once guessed simply harder to guess. Also, something like an ID is in my experience something that will be referred to orally between two human beings when discussing a problem, like referring to user 6201 or discussing invoice 540567. When you switch to UUIDs you're basically also saying "no human will ever have to say this out loud".
  - insanitybit 4y ago
    > "Protecting" records by making IDs hard-to-guess just seems like putting the responsibility in the wrong place. It's a pretty powerful implementation of capability based security.
    - yellowapple 4y ago
      I would hope that a capability-based security system entails considerably more than just knowledge of an ID.
    - yencabulator 4y ago
perakojotgenije 4y ago
integer/year works almost flawlessly as invoice ID. It is unique and readable. If the company has more than one unit that creates invoices than just add unit ID, so it becomes invoice_id/unit_id/year. Still unique and very much readable.
- yencabulator 4y ago
  To avoid the German Tank Problem and leaking your business vitals to competition, I'd recommend making invoices be scoped to the client, e.g. <client_id>-<number>. And then client_id is either random or for small business e.g. unique slug derived from client name, for example you could get PERAK-0001. https://en.wikipedia.org/wiki/German_tank_problem#Historical_example_of_the_problem https://en.wikipedia.org/wiki/German_tank_problem#Historical...
spookthesunset 4y ago
At some point those sequential integer ID's will become so long they might as well be GUIDs. Of course you could "compress" the integer using some kind of encoding scheme similar to base64. Then your long integer becomes a few characters. ... Maybe though. Even ID's in the millions are probably easier to read than a long ass GUID.
- yellowapple 4y ago
  > At some point those sequential integer ID's will become so long they might as well be GUIDs Worth bearing in mind that an unsigned 32-bit integer sequence can uniquely identify 4,294,967,295 records. If you're really storing that many records (let alone enough to exhaust an even bigger integer sequence), the length of the identifier is probably the least of your worries :)
meekaaku 4y ago
Standard accounting practices require that invoices/receipts have sequential numbers. So it has to be integer, or some kid of sequential alphanumeric. Even if one uses UUID as primary key, it should have separate invoice_no (in whatever formatting they require such as 2023/001, or 1001,1002...) which is the human readable and referenced number. This is especially important if you are developing a multi-tenant system where the invoice number, say 2023/001, may exist for more than one tenant.

brightball 4y ago

This is a very worthwhile point. You definitely need to prepare for readability if these ids will be customer facing.

craigkerstiens 4y ago
While not a perfect solution to it, we use UUIDs throughout our application as IDs. But when we expose them in URLs or other places provide them as an encoded id (https://docs.crunchybridge.com/api-concepts/eid/ https://docs.crunchybridge.com/api-concepts/eid/). It at least makes them a little more compact, easier to copy/paste than UUIDs, and generally a cleaner look.

mytailorisrich 4y ago

As it happens in at least some jurisdictions invoice numbers have to be sequential by law.

Scarbutt 4y ago
That's orthogonal to having a programatic ID for them

victor106 4y ago

Are sequential id’s a security risk? In one of our systems we’ve seen customer guess at other accounts by just incrementing the sequence. The rule of thumb I used to use is if an Id is going to be used for lookups or being exposed externally use uuid otherwise us sequential. The hard thing about the above rule is that it’s hard to tell when you are designing the db if the id will be used externally/for lookups or not. Requirements change later.

hnarn 4y ago
"Protecting" records by making IDs hard-to-guess just seems like putting the responsibility in the wrong place. If you're so worried about people getting their hands on the wrong records, I'd be more worried about your lack of trust in the application that queries that database in the first place: remember, even if you do make the IDs hard to guess, your "untrusted application" might at some point decide to simply leak the entire table instead. There are much better solutions for this, like server-side prepared queries that do not simply return on an ID but rather as the result of a join, or just proper security practices in general, rather than reactively making something that was once guessed simply harder to guess. Also, something like an ID is in my experience something that will be referred to orally between two human beings when discussing a problem, like referring to user 6201 or discussing invoice 540567. When you switch to UUIDs you're basically also saying "no human will ever have to say this out loud".
- insanitybit 4y ago
  > "Protecting" records by making IDs hard-to-guess just seems like putting the responsibility in the wrong place. It's a pretty powerful implementation of capability based security.
  - yellowapple 4y ago
    I would hope that a capability-based security system entails considerably more than just knowledge of an ID.
  - yencabulator 4y ago

perakojotgenije 4y ago

integer/year works almost flawlessly as invoice ID. It is unique and readable. If the company has more than one unit that creates invoices than just add unit ID, so it becomes invoice_id/unit_id/year. Still unique and very much readable.

yencabulator 4y ago
To avoid the German Tank Problem and leaking your business vitals to competition, I'd recommend making invoices be scoped to the client, e.g. <client_id>-<number>. And then client_id is either random or for small business e.g. unique slug derived from client name, for example you could get PERAK-0001. https://en.wikipedia.org/wiki/German_tank_problem#Historical_example_of_the_problem https://en.wikipedia.org/wiki/German_tank_problem#Historical...

spookthesunset 4y ago

At some point those sequential integer ID's will become so long they might as well be GUIDs. Of course you could "compress" the integer using some kind of encoding scheme similar to base64. Then your long integer becomes a few characters. ... Maybe though. Even ID's in the millions are probably easier to read than a long ass GUID.

yellowapple 4y ago
> At some point those sequential integer ID's will become so long they might as well be GUIDs Worth bearing in mind that an unsigned 32-bit integer sequence can uniquely identify 4,294,967,295 records. If you're really storing that many records (let alone enough to exhaust an even bigger integer sequence), the length of the identifier is probably the least of your worries :)

meekaaku 4y ago

Standard accounting practices require that invoices/receipts have sequential numbers. So it has to be integer, or some kid of sequential alphanumeric. Even if one uses UUID as primary key, it should have separate invoice_no (in whatever formatting they require such as 2023/001, or 1001,1002...) which is the human readable and referenced number. This is especially important if you are developing a multi-tenant system where the invoice number, say 2023/001, may exist for more than one tenant.