[gary_0]

I think you could extend this argument to include the philosophy that databases should be glorified key-value stores, and semantics should only be handled by application code.

I think a key point in the article is that "models become obsolete faster than we’d like".

On the other hand, you could argue that it's simply necessary to put in the effort to keep the data model up to date with your current needs, through API versioning, database migrations, etc.

Honestly I'm not sure which approach is less messy; maybe it depends on the team.

[paulddraper]

No.

The difference is that IDs are part of the public API.

Your database schema (KV or otherwise) is not.

[gary_0]

Generally the data model of the API resembles the data model of the DB schema. IDs that are generic numbers could be considered an aspect of a "flat" data model, where the application code assigns semantics to lists of data that are less strictly structured (and have less strict identifiers).

[paulddraper]

But what difference is there if you use KV stores or DBMS with strict schema? There is no consequence on your public interface.

That was the comment.