Re: Question about where to deploy the business logics for data processing

On Thu, Jun 8, 2023 at 10:22 PM Nim Li <mr(dot)nim(dot)li(at)gmail(dot)com> wrote:

> I wonder if anyone in the community has gone through changes like this? I
> mean ... moving the business logics from PL/SQL within the database to the
> codes in NestJS framework, and reply on only the TypeORM to manage the
> update of the database without any SQL codes? Any thoughts about such a
> change?
>

Heads up, this is something of a religious database debate in the industry,
and you are asking a bunch of database guys what they think about this, and
their biases will show in their answers.

Having said that, your developers are utterly, completely, wrong. This is
classic, "my technology good, your technology bad", and most of the reasons
given to migrate the stack boil down to "I don't know SQL any will do
absolutely anything to avoid learning it", to the point of rewriting the
entire freaking project into (wait for it) javascript, which might very be
the worst possible language for data management.

The arguments supplied are tautological: "SQL is bad because you have to
write SQL, which is bad", except for the laughably incorrect "sql can't be
checked into git". Guess what, it can (try git -a my_func.sql), and there
are many techniques to deal with this.

Now, database deployments are a very complex topic which don't go away when
using an ORM. in fact, they often get worse. There are tools which can
generate change scripts from database A to A', are there tools to do that
for NestJS object models? Is there automatic dependency tracking for them?
Next thing you know, they will moving all your primary keys to
guids ("scaling problem, solved!") and whining about database performance
when you actually get some users.

WHY is writing SQL so bad? Is it slower? faster? Better supported?
plpgsql is very highly supported and draws from a higher talent pool than
"NestJS". Suppose you want to mix in some python, enterprise java, to your
application stack. What then?

ORMs are famously brittle and will often break if any data interaction to
the database does not itself go through the ORM, meaning you will be
writing and deploying programs to do simple tasks. They are slow,
discourage strong data modelling, interact with the database inefficiently,
and do not manage concurrent access to data well.

merlin