I’m delighted to announce that we’ve just posted “Why use PL/SQL—the Movie” as a playlist on the Oracle Database Product Management YouTube Channel HERE.
It’s been a long time in the making. But I hope that you’ll think that, like for all good things, the outcome was worth the wait. These two conference presentations are the meat of the production:
We’ve also added three informal conversations to give you a glimpse of the back-story that brought Toon and me to our decision to ramp up our advocacy for the proper use of the Oracle Database at the heart of classic OLTP applications. We argue, each in our own rather different ways, that the database should be used as a processing engine rather than just as a bag of tables. Advocates of the bag-of-tables approach usually refer to the database as the “persistence layer”—presumably in the hope that using this term will dress up that sow’s ear as a silk purse. But Toon and I prefer to call a spade a spade—or, for brevity, the NoPlsql approach.
Check out the playlist for these:
There’s a few other pieces of light-hearted footage, including “Jenny Tsai-Smith and Bryn Make a Plan” where I try—and succeed—to persuade Jenny to provide videography resources from her team to make our movie.
You might like, mentally, to add THIS other YouTube video to the playlist. It’s called “NoPlsql and Thick Database Approaches with Toon Koppelaars”. Because it was published in the Fall of 2016, and has already received thousands of views, we decided to leave it as a stand-alone piece. It gives the full detail of the “flame graph experiment” that was conducted and analyzed by members of Oracle’s Real World Performance Group. Toon refers to this experiment in his Kscope17 deep dive session. But the duration of that session didn’t allow more than just a summary.
The earlier pieces in the playlist use the term “Thick Database” about the approach that Toon and I advocate. Both this term and “Fat Database” have been used by various well-respected speakers and bloggers for a decade or more. Both “thick” and “fat” resonate with the visual metaphor of drawing a software stack as horizontal layers, like a stack of pancakes. When all the SQL statements that manipulate the application’s tables are issued by PL/SQL code in the database, the database pancake is thick and correspondingly the middle tier pancake is thin. However, we were persuaded by our Oracle colleagues to switch to “smart” because it better captures another crucial aspect of the paradigm. Not only is all the SQL issued from PL/SQL code; but also, set-based SQL and bulk-binding techniques are used to the full, and the full power of Oracle Database’s rich feature set is exploited. In other words, not only are we encapsulating the database with a hard shell PL/SQL API; but also, we’re using the database in a smart way. This stands in stark contrast to the approach that aims to be database vendor agnostic and that limits itself to just a universally available, and therefore very basic, set of features.