How you should or shouldn’t design, program for, a performing database environment

My good friend Toon Koppelaars created a cool and very interesting, learning video about how to design, program for, a database environment. He is describing in great details the positives and negatives of, for example, SQL inside or outside the database and the effect it has, among others performance. 

As described on the description of YouTube for this nice mini-training:

Toon Koppelaars describes an experiment to measure the work done by Oracle Database to complete a specific task using different approaches. The NoPlsql approach treats the database as no more than a persistence layer, using only naive single-row SQL statements; it implements all business logic outside of it. The Thick Database approach treats the database as a processing engine; it uses a combination of sophisticated set-based SQL statements and PL/SQL to implement all business logic inside it. “No business logic in the database” advocates take note: the Thick Database approach gets the task done with far less database work than the NoPlsql approach.

(if not only how to save on CPU licenses – a customer of mine had to add to CPU’s yesterday on their Exadata machine because of reasons explained)

Anyway have fun in learning how to do it properly or be amazed by the results.

 

HTH/M

 

PS.

Want to see Toon in action, if your in the neighbourhood, have a look/register for: The Database: a Processing Engine, or a Persistence Layer?

Marco Gralike Written by: