On Thu, Jun 8, 2023 at 10:22 PM Nim Li <mr.nim.li@xxxxxxxxx> 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
