The Brilliant Concept: a DB-centered architecture
The presentation shows the use of a Thick-DB concept a database-centered architecture: good and bad.
From the diagnose-data of a badly performing system we show the symptoms, and how the “root cause” was identified. Via the diagnosis we show some possible fixes and their limitations. This system was in fact a very cleverly built “Thick DB” application. But even a good concept on EXA-llent hardware can be abused to the point where users complain.
After this presentation, attendees will be able to make better-informed decisions on the use of stored procedures and notably the use of functions.
The DB-centered approach is Good, and often perferable. But beware of mistakes and exaggerations.
The System was built with a very generic data model, and with the aim to be "flexible". This led to too-many views, and to a set of stored procedures that provided "extra functionality" for many individual columns in those views. After a few years of development, the system became very CPU-intensive. Hardware-capacity could keep up with the demands for a few years, until a major increase in data-volume strangled the CPUs. Even an Exadata-machine was not capable of delivering sufficient response-times.
The presentation will "dig into" the layers of well-intended functionality to try and show what happened. There are some very good+clever ideas included in this app, but... cpu-heavy. The "symptoms" were fixed by:
1) remove unused columns from views
2) remove unused code and bypassing conceptual layers, and
3) a code modification using function-result-cache (=oracle specific).
