A JSON-relational duality view declaratively defines a mapping between JSON documents and relational data. That's better than mapping programming objects to relational data.

If you use an object-relational mapper (ORM) or an object-document mapper (ODM), or you're familiar with their concepts, then this topic might help you better understand the duality-view approach to handling the "object-relational impedance mismatch" problem.

Duality views could be said to be a kind of ORM: they too map hierarchical object data to/from relational data. But they're fundamentally different from existing ORM approaches.

Duality views centralize the persistence format of application objects for both server-side and client-side applications — all clients, regardless of language or framework. The persistence model presents two aspects for the same data: table and document. Server-side code can manipulate relational data in tables; client-side code can manipulate a collection (set) of documents.

Client code need only convert its programming objects to/from JSON, which is familiar and easy. A duality view automatically persists JSON as relational data. There's no need for any separate mapper — the duality view is the mapping.

The main points in this regard are these:

• Map JSON documents; don't map programming objects!

  With duality views, the only objects you map to relational data are JSON documents. You could say that a duality view is a document-relational mapping (DRM), or a JSON-relational mapping (JRM).

  A duality view doesn't lock you into using, or adapting to, any particular language (for mapping or for application programming). It's just JSON documents, all the way down (and up and around). And it's all relational data — same dual thing!

• Map declaratively!

  A duality view is a mapping — there's no need for a mapper. You define duality views as declarative maps between JSON documents and relational tables. That's all. No procedural programming.

• Map inside the database!

  A duality view is a database object. There's no tool-generated SQL code to tune. Application operations on documents are optimally executed inside the database.

  No separate mapping language or tools, no programming, no deploying, no configuring, no setting-up anything. Everything about the mapping itself is available to any database feature and any application — a duality view is just a special kind of database view.

  This also means fewer round trips between application and database, supporting read consistency and providing better performance.

• Define rules for handling parts of documents declaratively, not in application code.

  Duality views define which document parts are shared, and whether and how they can be updated. The same rule validation/enforcement is performed, automatically, regardless of which application or language requests an update.

• Use any programming language or tool to access and act on your documents — anything you like. Use the same documents with different applications, in different programming languages, in different ways,….

• Share the same data in multiple kinds of documents.

  Create a new duality view anytime, to combine things from different tables. Consistency is maintained automatically. No database downtime, no compilation,.... The new view just works (immediately), and so do already existing views and apps. Duality views are independent, even when parts of their supported documents are interdependent (shared).

• Use lockless/optimistic concurrency control.

  No need to lock data and send multiple SQL statements, to ensure transactional semantics for what's really a single application operation. (There's no generated SQL to send to the database.)

A duality view maps parts of one or more tables to JSON documents that the view defines — it need not map every column of a table. Documents depend directly on the mapping (duality view), and only indirectly on the underlying tables. This is part of the duality: presenting two different views — not only views of different things (tables, documents) but typically of somewhat different content. Content-wise, a document combines subsets of table data.

This separation/abstraction is seen clearly in the fact that not all columns of a table underlying a duality view need be mapped to its supported documents. But it also means that some changes to an underlying table, such as the addition of a column, are automatically prevented from affecting existing documents, simply by the mapping (view definition) not reflecting those changes. This form of table-level schema evolution requires no changes to existing duality views, documents, or applications.

On the other hand, if you want to update an application, to reflect some table-level changes, then you change the view definition to take those changes into account in whatever way you like. This application behavior change can be limited to documents that are created after the view-definition change.

Alternatively, you can create a new duality view that directly reflects the changed table definitions. You can use that view with newer versions of the application while continuing to use the older view with older versions of the app. This way, you can avoid having to upgrade all clients at the same time, limiting downtime.

In this case, schema evolution for underlying tables leads to schema evolution for the supported documents. An example of this might be the deletion of a table column that's mapped to a document field. This would likely lead to a change in application logic and document definition.