PL SQL for business logic ? Data intensive i agree its fine
Dhrub, February 21, 2024 - 3:10 pm UTC
I am completely aigned to your view , its a good choice to use plsql for data heavy operation . .that answers my 2nd question on data engineering
But i am not sure if you can answer the same for both , because in later your taking about Peta byte of data in the former you have transactional user based data . .it may be huge too .
But for Business logic i see almost all project implement the business logic in the code using Java 9 or .Net . .. . db is limited to only curd operation via the orm .
in that way do you shet light on same .
February 26, 2024 - 5:53 am UTC
I suppose I always chuckle when a dev team will say:
"This is BUSINESS logic so we're doing it in Java. Its not a DATA logic function"
and then I ask, "OK, what is the basic function" to which the reply is:
"We get some data from here, here, here, and here, and from there, and also here, and here, and here....and then we do BUSINESS logic. No data logic at all"
:-)
What is "business logic"?
Stew, February 22, 2024 - 11:16 am UTC
If the result of "business logic" is something that must be persisted, then it is actually "data logic".
It seems to me that "data logic" is of two kinds:
1) Rules governing data and data relationships that should always be respected, meaning constraints and "assertions"
(This kind of rule must be enforced whenever the data is created or changed, whether by "business logic" or "data engineering".)
2) Logical "units of work", meaning transactions.
The first kind should be implemented in DDL if possible. Where "assertions" are concerned, it's more complicated. A simple example of an assertion: in an employee table, only one row can have the job of PRESIDENT. I would say that PL/SQL or not, the implementation of this rule should be in the database.
The "smartDB" approach was all about transactions. It dictated that client code was never allowed to do SQL: all it could do was call transactional APIs written in PL/SQL. As Connor stated, there may be reasons to share the load with the client code.
I suspect that JSON Duality Views in version 23c could provide an alternative to PL/SQL in many cases, since they are APIs both for accessing and changing data.
The important things to me are to respect relational and transactional logic, and to avoid losing time in multiple round trips between the client and the database. If that's my job and the database is Oracle, then I want to know PL/SQL and SQL.
In my former company, stored procedures were outlawed and ORMs were mandated, but all the "devops" stuff (creation of tables, test data, etc.) was written in PL/SQL and SQL! Even if you take PL/SQL out of the application, you can't take it out of the project...
Best regards,
Stew
February 26, 2024 - 5:49 am UTC
Thanks for stopping by Stew. Always appreciate your input.