I like the idea of making the jacket subprogram (“Pkg.Bulk_Insert” in the slide) a little smarter. I’m also thinking out loud here. I’m unclear on the purpose of issuing a rollback at the start of an autonomous transaction. There is nothing to rollback. And it leaves a pending transaction silently pending.

In any case, SmartDB should require making sure an API is smart enough to not commit something unknowingly handed to it. In our current application, I caught ourselves making human mistakes of committing data that wasn’t part of the transaction (while doing other things in other SQL Developer windows). But I also didn’t want to issue a rollback without giving it due consideration. What I decided to do is have the API (if it might change the database) explicitly start a transaction. If it succeeds, things may proceed safely. If it fails, the error is logged and re-raised, passing it back to the caller to handle.

I’d welcome feedback on this alternate idea. Maybe Bryn’s idea that leaves a pending transaction as-is is more flexible. I’d still like to know the intent of that initial rollback.

These are interesting thoughts. Thanks for sharing.

I considered the definitions here part of the “Hard Shell” paradigm rather than the “SmartDB”. These definitions just seem to be changing the interface or representation of the data in the database from relations to be operated on by SQL statements, to procedural modules. Although there may be intimations from doing this, they are not logical deductions from these statements.

I considered a “SmartDB” to be one that fully implemented a data model within the DBMS; where a data model meets the definition specified in Codd’s paper Data Models in Database Management:

…a combination of three components:

a collection of data structure types (the building blocks of any database that conforms to the model);
a collection of operators or inferencing rules, which can be applied to any valid instances of the data types listed in (1), to retrieve or derive data from any parts of those structures in any combinations desired;
a collection of general integrity rules, which implicitly or explicitly define the set of consistent database states or changes of state or both.

So that any business rule that could be implemented within the DBMS as an integrity constraint, either declaratively as an SQL constraint or assertion or programmatically using triggers would be.

This, I thought, was also the basis of Toon’s Helsinki Declaration which stated that data logic should be moved into the DBMS; and his and Lex’s book “Applied Mathematics for Database Professionals” which showed a method to implement this.

I could stop at this point safe in the knowledge that no-one could unwittingly compromise the integrity of the data within the database.

Or the “Smart DB” could be extended by implementing a “Hard Shell” to address other requirements, such as performance, where as much additional business logic as possible is implemented within stored procedures in the DBMS.

So, in summary:

A “SmartDB” is one in which a data model is fully implemented within the DBMS using declarative or programmatic integrity constraints.
A “Hard Shell” is one in which as much business logic as possible in implemented within stored procedures, and calling stored procedures is the only access outside-of-the-database code can make.