The NoPL/SQL and Thick Database Paradigms, Part 2
We have many years of extensive hands-on experience of building, and tuning, applications that use Oracle Database. We have seen two mutually incompatible architecture paradigms. The thick database paradigm, preferred in the 1990s, starts with the design of the relational model. This leads naturally to the encapsulation of all insert, update, delete, and select statements within PL/SQL subprograms that expose the database interface. The NoPlsql paradigm, which seems now to be the preferred choice, starts with an object oriented domain model in the middle tier, and leads naturally to treating the database as a bag of tables, letting the primitive SQL statements that manipulate these express the API.
The widespread adoption of the NoPlsql paradigm has made the world a worse place, and so in Part 2, we explain the thick database paradigm, rehearse the reasons for its superiority, and describe how to adopt it. The paradigm implies more than just allowing database calls to invoke only PL/SQL subprograms. We formalize a layered code classification scheme which leads to optimal understandability and maintainability of both your PL/SQL and your SQL code which properties bring the maximum probability of correct behavior. This approach establishes the database tier as a reliable central service provider in your application landscape. We will convince you that following the thick database paradigm, and implementing your business functions within the database, guarantee the avoidance of the awful problems brought by the NoPlsql paradigm.