O Schema, Schema, wherefore art thou Schema

I have been grappling with this issue for years now. And it is this: how to unify data representations across display (you know, the part the user gets to see), code (the fun part we deal with) and the storage (cumbersome things like databases, files, etc). Or in other words, Views, Controllers and Models.

One of the issues here is where do you define the data? Sure you can transform the data from one place to another, but where is the canonical definition of the data? DBA's want this to be in the Schema of a SQL database. Programmers have a different idea: it should be embodied in code objects which are then propagated to the database. That seems wonderful at first (unless you are a DBA) because then the code can convert both ways; it can generate/update the DB Schema and it could generate Views for display. I had toyed ways of defining the schema in code...

But the problem here is that SQL databases are very egotistical. They know exactly what they are, what they can do, and where, and don't really like that being changed on a programmer's whim. And they already have this very thorough mechanism for defining that data and the relationships therein. Why try to duplicate that in code and go through the contortions necessary to convert object definitions into schema definitions (never mind the subsequent object to data remapping needed)?

If you're working with a SQL database, then you should just accept that the database is the owner of the data schema. You should make your changes there, and have it propagate "upward" to the code.

If you want your code to be the boss of the schema, then consider using a schema-less (NoSQL) database. These are like the savants of databases: they dont know what they are storing and don't care, they just do it fast. That leaves the schema definition to the code.

So what's the point? Just that you should know and accept where your schema is. Use the right tool for the job. yadda yadda.