What does devrant think about custom IDs?

Instead of:
- "d2ac9db1-3222-4e99-97cb-e14fb4240f43"

Something like this:
- "user-d2ac9db1-3222-4e99-97cb-e14fb4240f43"
- "document-34ea29ce-6022-40d4-821d-95b240633ba9"

They can be saved as binary in DB (like in the old days before native UUID support), have basic protection against being confused with IDs of another prefix and are pretty much self-documenting (better debugging/logging experience).

Plus, every ID would have their own value object (increased type safety) and if required, prefix can be omitted for 3rd party systems.

I think, it would be well worth it... 🤔

And why exactly do you want anyone to have the same handle as someone else but different ID?

Kinda pointless,
For nosql the document storage would be called "user" or "document" or "posts" for example, you would already have context of where the uuid belongs based on what you're looking for anyway.

Unless your using a single flat file with everything in it, then yea, I see how you would want to actually delineate these things, but the design is probably wrong anyway 🤷‍♂️

All generated ids should be treated as opaque types, incomparable with ids from different domains. It really bothers me when people type everything as string - especially uuids.

UUID is named so because it's universal.

Once you start to prefix items to it you lose the universal part of it.

You want a model that scales? You want a service that runs like a machine? Leave UUID alone and change the key name that your UUID is stored as.

It's a standard for a reason. It's my meant to be read by humans.

I was mostly thinking about handling IDs in different services within a domain. For example between the BE, a REST-API and the FE.

GET- requests are mostly flat:
- /api/example/<ID>
- /api/example?id=<ID>
- /api/example?example[id]=<ID>

But mostly I want a correct system lol

@SuspiciousBug

/api/<Type>/<ID>

Type being the content your asking for (user, document, etc.) and the id being well... the uuid.

Keep it simple.

Just add a different column if it’s sql or kv if nosql. Much easier to query, and can be indexed.

What do you want...

A PK.

What is a PK?

A unique identifier.

In your case, you made a compound key.

You now have a PK consisting of a set of two informations - type and UUID - concatenated to a unique string in a single column.

There are valid use cases for special primary key constructs (e.g. in distributed systems with replication) - but unless you absolutely need it, always follow the most important rule in database design: Don't add complexity unless necessary.

You waste a lot of resources with zero gain - except for a better human understanding, though even that is rather "debatable". Debatable as the information what "type" / table is used should be solemnly known in the backend and not anywhere else. PK usage in the frontend *can* be a dangerous thing - even more when the PK is a compound key and the frontend relies on e.g. the information stored in the compound key... Cause then you will never be able to decouple backend from frontend.

Aka: It's dead, Jim.

Time to rewrite.

If you do it for easier debugging by humans, it is fine. If you actually plan to have code matching/parsing the type information in the IDs it's a pretty darn stupid idea.

@sariel
Wait what?

Assume x is a universal unique string. How does adding something to it like this "prefix-" + x make it less universal or unique?

I think the prefix is a waste of space, but it doesn't take away from its uniqueness, since that's a quality of the whole string.

I'm really trying to think up a way how your statement could be correct. Are you trying to say that every unique string most be a prefix free language or something like that? Because that can be easily remidied by saying that after the last dash it is a uuid.

@TheCommoner282 because now you can have two uuids that are effectively the same.

"user-4fac7e8a-fccd-4471-a144-d43d3e94167b"

"document-4fac7e8a-fccd-4471-a144-d43d3e94167b"

These two are the same ID, they just have two prefixes. Now fast-forward 10 years and your tables have billions of records in them and you need to consolidate them into a single document store without the prefix. Are the records related? Are they the same? How do you propose we consolidate them? We could generate new UUIDs for them, but which one? Now we also need to update any other tables with the new ID.

If we keep to the standards we have far more options than if we fuck with it.

UUID was developed in the 1980s for the Apollo mission and has been further developed by the IETF since. If a dev thinks they know better than at least 100 engineers over 40 years of work then they can open a RFC to set a new UUIDv5 standard.

Changing it is just madness and makes 100x more work than needs to be.

@sariel
If we do not change the creation method of the uuid, but only add a prefix, how is it likely to create two identical ones?

Or let me rephrase that, I know there is a tiny likelihood. How is it more likely than normal when you do that in two different tables/collections?

To the best of my knowledge, there is no uniqueness check between tables/collections. Only within.

@TheCommoner282 it's not a matter of how or if, but when. In the examples users and documents are actually really good examples of when you want to use UUIDs.

You would want to use these as independent tables just so they can scale appropriately. Because they are separate you wouldn't ever need to check for unique UUIDs cross-table.

I gave a poor example by using users and documents prefixes. You would likely never merge those two tables together. But, if you set the precedent for prefixes you will undoubtedly use it on a table that may be merged.

At the time when these tables need to be merged, coordination will still be required.

I just don't understand why anybody would want to go against a well-known standard and set useless information as a prefix to a generated ID.

It would be like saying you don't like to use port 443 because most servers are attacked on that port so you forward all traffic on port 334 to 443 through a firewall.

It's standard for a reason, don't change it.

It's base16. "User" isn't valid base16. Now you forced yourself to encode very obviously base16 data as a string.

don't.

please don't.

just don't.

DON'T.

DO! NOT!

just use uuids as they are and be done with it. don't fix what ain't broken.

You're thinking of an informal URN

@lorentz this, all this.

@sariel

I need to make it clear that I agree that prefixing it is a bad idea. But mostly because it is a waste of space. The argument "it is a standard for a reason" is terrible. It's like it's gospel. Don't question the standard.

But anyway, your argument does not fly. If I have a function UUID which returns a uuid-value up to code, it will be unique.

So, if x and y are returns from that UUID function, x != y. (Astronomical low chance of overlap)

If I know prefix it, it won't change that they are unequal, because those words end on different strings of the same lenght, let px and py be the prefixed versions of x and y, then px != py != x != y.

Now removing the prefix later, if I merge it or I don't, if it was saved in one table or two different, that won't affect how they are different.

I don't see how this reduces their uniqueness anyhow.

@TheCommoner282 I'm not saying don't question the standard. Please by all means question the standard. Open up a request with the IETF and request them to make changes to the standard.

But please, for all future developers that will maintain your shitty app, do not change a standard to fit your business need.

Ask any senior developer with at least 10 years of experience in enterprise solutions and they will tell you what I'm telling you. You want to make a unique identifier? Make your own standard. Make sure you have the 3000 pages of documentation that back it up though.

It drives me insane when "nobody" developers think they know better than a collective 300+ years of experience from the best architects in our career.

Again, question the standard. But do it through the proper channels. You want to go off and do your own thing, don't get pissed when I throw you under the bus and throw your trash app in the fire.

@sariel

You're really on and on on this standard thing. So far we have only heard an idea. The idea is on the level of "what do you guys think."

And the point I am actually criticising about your comment remains ignored

@TheCommoner282 just because you don't understand it doesn't mean that it's wrong.

Go read the documents for UUIDs.

Imagine if IPv6 allowed you to inject the asset tag as a prefix. Could you imagine how chaotic that would be?

Now imagine that the NEC doesn't exist in North America. Some outlet terminals are made out of brass, some made out of copper, now some are made out of wood with brass plates. Now some are made out of steel. Others made out of PVC with copper plates. And then the wires are coated with kerosene soaked rags for insulation.

I can see you sitting on your front lawn while your house burns to the ground screaming "but they're all plugs and wires! Why is my house burning?"

When you ignore standards that are set by people that are much smarter than you, you open yourself up to risk.

You can ignore the standard if you want but you don't get the option to bitch when your shit breaks, and the developer that takes your job because you're an idiot will hate you.

@sariel

Honestly?

I do see why you believe those people are much smarter than you...

Alright...

Try to understand my criticism. Your argument is wrong! Not the argument about general standards. The argument about merging and lessening uniqueness. I want you to defend that.

The other thing is a straw man. I don't argue against it. I generally look down on people using the phrase "people much smarter than you." It's an argument from authority.

But this is not my argument against you. I explained it twice. And I reiterate: Back up your previous statement about the uniqueness or retract it.

@TheCommoner282 you clearly can't read. Let's see if this helps.

@sariel

Exactly. I read that. Here is my reading comprehension:

Quote:

"But, if you set the precedent for prefixes you will undoubtedly use it on a table that may be merged."

Implying that this would be a problem. I keep arguing that we would have same length UUID suffixes on those strings and as such they would be unique with the prefix and even if you suddenly took the prefix away and threw 'em in the same table. They are still unique. Merging wouldn't be an issue. I keep reiterating this.

@TheCommoner282 uuids aren't fully unique though.

Sure they are pretty damn close, but a uuid can be duplicated.

You'll still need a dupe check either at Code or db level to handle the odd one.

@C0D4

It's often underestimated how close they come to uniqueness.

Let me link a relevant Stack Overflow for this: https://stackoverflow.com/questions...

You can normally blindly merge two tables of different application when they have UUIDs. The chances of something going wrong are tiny. And tiny off chances are just a bit of error handling.

@TheCommoner282 it's not a matter of if but a matter of when.

Also, "just a bit of error handing"? What planet are you from? If you can't trust 0.0001% of your data integrity you can't trust any of it. At that point it no longer becomes statistically relevant.

I think I know what your opinion is now, you hate standards because you can't follow them because you THINK you're smarter and better than them. Good luck with that, you're going to need it when all your shit falls apart.

I bet you have some ideas on how JSON should allow numerical keys too. 🤣

@sariel

Good source of entropy and you go a hundred year with a billion uuids per year before you reach 50% probability of having a duplicate ID.

Not too shabby, isn't it?

And now you think about what you might be losing. That depends on the database. Let's say you merge two databases and you get a duplication error. Well, if it is something like the current catalogue of watched tv shows, you can live with a random episode being untagged once every 200 years.

If it is money related, yeah, you have to do smarter error handling. Not just drop the entry. You have to check beforehand if there is a conflict. If it's a once in a lifetime change, you can just check if it will have overlaps with each other and run the migration. If you find one, you will have to write a renamer (or if it's just one entry do it manually, but follow all foeign keys). But chances will still be tiny.

I am still not arguing about standards. That's your windmill.

Oh wow, I didn't expect this question to blow up! 😅 Thank you all for your feedback. I'm mostly concerned with making everything idiot proof; so getting a fresh perspective helps a lot. I think, I'll just stick to normal UUIDs then 👍

How would you query this database? Using substr() in every query? I don’t get it

@MegaLeetBro
Either a) by using native UUIDs in DB and just getting the UUID from the ID (value object) or b) by saving as binary (instead of text) in DB (with prefix) and getting the UUID with prefix as binary.

The ID is (of course) a value object:
- someMethod(UserId user, DocumentId document)

Instead of:
- someMethod(Uuid user, Uuid document)

Or even:
- someMethod(string userId, string documentId)

@SuspiciousBug its fine to clobber Month/Day/Year into 1 column and call it DateTime. But for your application, I would consider 2 columns.