Usually there is a 1-1 mapping between an object in the application layer and a table in the database layer.
This coupling leads to complexities whenever there is a database schema change and the application version may not be compatible with the current database version that it is talking to.
I was reading that there is an approach of database design that is driven by metadata. Something like the fields available for an object is found from a table and then a query is done. So some form of direction in order to avoid versioning problems.
Is this approach used in general and how exactly is it implemented? Also are there are other approaches to deal with this issue?
Database Design – Avoiding Versioning Inconsistencies Between Application and Database Layers
application-designdata-tier-applicationdatabase-designorm
Best Answer
The approach you're think of is called Entity-Attribute=Value (EAV). If you Google around for it you'll find very quickly that it is almost universally reviled. In short, it's generally a bad idea because it doesn't let your relational database management system do what it was designed to do.
As an alternative, you should think about schema changes as something that you need to keep backward compatible. This often means that new columns will be nullable or have defaults set. Depending on what you want to do with your application, though, sometimes a database change is simply a breaking change and you can't release the database change without releasing the corresponding code change.
I've seen some people keep a short code table in their database that contains version information in it (e.g. minimum and maximum supported code versions). The idea with this is that when your application starts it does a quick lookup in the code table and if the database version isn't compatible with the code the code exits gracefully.