Even in OO there is a constant tension between the OO/Relational realms that Scott Ambler reviews in a series of articles:
- Why Data Models Shouldn’t Drive Object Models (And Vice Versa)
- The Object-Relational Impedance Mismatch
- The Cultural Impedance Mismatch Between Data Professionals and Application Developers
- Mapping Objects to Relational Databases: O/R Mapping In Detail
It really boils down to the inconvenient truth that the relational model and the live execution model(s) can serve some very different masters (especially in complex systems) and therefore need some freedom to evolve into separate directions when necessary.
The relational model is dictated by it’s primary responsibility - either as an OLTP store, optimized for storing “data at rest” and finding certain subsets of the stored data relatively quickly and updating it as necessary with some efficiency or as an OLAP store (e.g. using a Star Schema) for reporting queries.
The various data structures within an application (or service) essentially capture “data in motion” and their structure and shape has to directly support the capabilities of the application. But as a compromise that data may need to drag around some shadow information to make it possible to correctly persist the transformed data later.
