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

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?