[feoren]

So your IDs are now tightly bound to whatever "types" you've currently decided you have, forcing a narrow view of what an entity is and making the entire system extremely brittle to change? What is a "type" even supposed to be? This is forcing a doubling-down on an already problematic design principle: that every entity is exactly one type of thing and these types of things are completely different than those types of things and obviously you can just make the perfect set of types that will never change if you think think really hard and everyone will agree on what each type means and they'll never change and that will never be a problem.

Jesus, what a nightmare.

[michaelsalim]

A quick glance of the repo shows that the "type" is just a prefix. You can do whatever you want with it. Basically the same thing as what the article suggests, no?

[likium]

You face the same issues with table names though. So do you not name your tables?

The solution to your entity problem should be the same. You do the reasonable, practical thing, and rename/refactor if they drift away from the original mental concept.

[feoren]

> You face the same issues with table names though.

Exactly right. You've succinctly stated the biggest problem with almost all modern database design.

> So do you not name your tables?

I do, but that name does not represent a Type of Entity, where all entities therein are Exactly Thus, and all entities everywhere else are Absolutely Not At All Thus. Instead, it represents a statement I want to make about entities. Any "natural" meaning you put into your identifiers about what they are is defeating the point of the identifier.

> You do the reasonable, practical thing, and rename/refactor if they drift away from the original mental concept.

And now all of your IDs that are "in the wild" have expired. Can I still submit a request using the old ID, before you renamed Employee to WorkPerson and then to MobileLivingBeing and then to PossiblyMobilePossiblyLivingBeing? And it's not "if" they drift away, it's "when". And it's not just that they change over time, it's that they change from one perspective to the next. You can never have two distinct disciplines of the business ever referring to the same entity, because they don't agree on what the types mean. That bears repeating: you can never have two different disciplines both referring to the same entity unless they agree on what the types are, and they don't, because their terms have different meanings. Do your accountants and your maintenance people and your capital planning people and your corporate leadership all agree on exactly what a "facility" is? Because if they don't, they literally cannot even refer to the same entity. Good luck with your microservices.

[bmicraft]

All I'm getting here is you're against names and labeling things. But you don't provide any solutions and since a heap of untagged and unlabled or in any other way annotated data seem so obviously strictly worse I doubt that's what you're actually suggesting?

[feoren]

As I said: the name represents a statement I want to make about entities. Naming things is fine. I'm against categorizing things.