[joshuanapoli]

Over time, the internal data model might need to change to more accurately model the world. For consistency and efficiency, we usually do not want to maintain the combination of the original low-fidelity model and new high-fidelity model within the internal database.

The internal data model might need to be reorganized to improve the efficiency of part of the internal application.

A client might not need a higher fidelity model. The internal reorganization of the data model might not be pertinent to the client's interface. So we normally have some data-mapping in the application to help provide a stable interface for clients.

It's possible to providing these compatibility mappings within the database through views, but this is usually considered to be harder to control, test and scale.

Maybe in a big application, the application-layer mapping and caching eventually get complicated enough to be something like a custom-made database. And so we might end up with an "integration database" but call it something different.

[dennisy]

Great thanks.

So we have a DB and a service in front of it. The DB gets a new schema, but the service maps to the previous representation in such a way that clients do not need to know about the new schema. Is that the gist?

Then when it comes to using Fauna, what is it that does not allow such a data flow?