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 🤷‍♂️

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.

@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.

@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.

@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.

@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.

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

@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.

@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. 🤣

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.