> On Jun 8, 2023, at 8:21 PM, Nim Li <mr.nim...@gmail.com> wrote:
>
> Hello.
>
> We have a PostgreSQL database with many tables, as well as foreign table,
> dblink, triggers, functions, indexes, etc, for managing the business logics
> of the data within the database. We also have a custom table for the purpose
> of tracking the slowly changing dimensions (type 2).
>
> Currently we are looking into using TypeORM (from Nest JS framework) to
> connect to the database for creating a BE that provides web service. Some
> reasons of using TypeORM are that it can update the database schema without
> any SQL codes, works very well with Git, etc. And from what I am reading,
> Git seems to work better with TypeORM, rather than handling individual batch
> files with SQL codes (I still need to find out more about this) Yet I do not
> think the ORM concept deals with database specify functions, such as dblink
> and/or trigger-function, etc, which handles the business logics or any ETL
> automation within the database itself (I should read more about this as well.)
>
> Anyway, in our team discussion, I was told that in modern programming
> concept, the world is moving away from deploying programming logics within
> the database (eg, by using PL/SQL). Instead, the proper way should be to
> deploy all the programming logics to the framework which is used to connect
> to the database, such as NestJS in our case. So, all we need in a database
> should be only the schema (managed by ORM), and we should move all the
> existing business logics (currently managed by things like the database
> triggers, functions, dblink, etc.) to the Typescript codes within the NestJS
> framework.
>
> 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?
>
> Thank you!!
>
You’re riding a pendulum which has swung too far.
In any organization of even minimal complexity, the physical data model and the
deployable business model are never well aligned: the usages of the data are in
a different dimension than the storage and maintenance of the data. I’ve not
heard of TypeORM but on this list ORMs are notorious for generating poorly
performing queries. The notion that application programming will replace
database triggers is ludicrous.
