Following is a white paper which is written by Wolfgang Flatow one of the uniDap Technology founders.
This white paper is intended for the technical audience who is interested in behind the scenes stuff and the architecture of uniDap.
The white paper which can be downloaded here is called:
Application Schema Binding
Consequences for Conventional Architecture
How uniDap removes the consequences
Following is an excerpt from the white paper
Database schemas become very complex with typical table numbers up to several thousand, with as many relationships, with tens of thousands of columns. As developers need to build their applications to reflect the database schema complexity (see ASB below), the application itself, its SQL, object code, XML and XSL MUST reflect the database schemas complexity.
As there is a huge investment in application development for every custom schema, the schema requires careful expert design to match an applications requirement specification. This in turn means that the requirements specification must reflect the comprehensive storage requirements and feature set of the application. Any changes or additions to this specification are likely to have very expensive consequences, as they lead to schema changes and ASB Consequences (see below)
There are also a number of data storage requirements that are extremely difficult to engineer using CA.
A typical example is a requirement to maintain change history (who changed what and when) of a records field (or column). If this was a system wide requirement you will need to incorporate a change log table using ‘implied’ relations linking it to the corresponding table/record/field (probably a text path). You cannot use a proper database relationship with referential integrity, because a records field (or column) does not have an ID, and you cannot create a relationship to a Records field.
