This is a transcription of Bryn Llewellyn’s talk Guarding Your Data Behind a Hard Shell PL/SQL API—the Detail recorded at Kscope18. It covers the time between 08:06 to 11:03. This definition was the starting position for my previous SmartDB and PinkDB-related posts.
In the meantime, Bryn provided an updated, narrow definition of the Smart Database Paradigm (SmartDB). I recommend to stop reading here and instead read the next post.
SmartDB Definition – Kscope18 – June, 12 2018
This is another way of finally summarizing the notion, the Smart Database Paradigm, whose hashtag you see there.
This is if you like the basic definition of it. We ensure that this primitive anonymous block (this is what we encourage, that is the only thing that is allowed to do anything when you do a database call), can only do, what the second thing shows. So, the first is the principle in words, and this is the principle illustrated in code. Okay.
And finally, if we say this is the basic central axiom of the Smart Database Paradigm, then what we see here, in Euclid’s way of seeing the world, is a theorem. And the theorem is, that
insert,update,delete,commitandselectand for that matterrollback– I said them in funny order, but you know what I mean – the classic SQL statements that are sufficient to implement an ordinary OLTP application, they can come only out of PL/SQL code. Okay. You see that, that’s just a theorem following from this simple axiom here stated in words and reinforced here in an illustration.
So then. And the final bit of the definition of the SmartDB paradigm is squishy. Everything I’ve said up to that point is hard and fast. You could walk up to a database, interrogate a few people, connect, do a few queries and you would soon see, hard shell or not.
The next bit you wouldn’t see. You would have to establish it and it’s a sliding scale. But basically, it says that everything that’s done to establish the world that’s exposed by the hard shell is done by intelligent, mature human beings, who’ve studied their trade, and have really done the whole thing. Designed the optimal set of tables and constraints, the optimal data model. They know SQL inside out and they know how to write the best SQL for the best use case. They know how to take advantage of set-based SQL in the ordinary sense, analytic functions, match recognize, you name it. It’s their stock-in-trade. And of course, they know also how to write PL/SQL.
But in this way of thinking about this world, I have to say, that the PL/SQL is typically no more than a kind of orchestration glue, whose purpose is to issue the SQL you’ve designed against the optimal data model, that you’ve designed. In other words, this is old-fashioned and unashamedly so, there’s no frameworks, there’s no point and click, it’s genuine intellectual achievement by people who’ve practiced their trade and being prepared to study what’s needed to study to get that far. And that part, of course, of SmartDB paradigm is harder to pin down.