Re: Rationale for aversion to the central database?

> That seems un-pragmatic to me. IMHO if any business logic needs
> access to lots of data, it's best implemented by code that
> resides in the database itself, close to the data. I once had a

There is a balance: ETL and reporting code is often iterative
and can be more flexable in an external language.

Getting the balance right takes some thought, planning -- both of
which are usually in short supply on software projects.

Testing database code and structures is easy in PG using TAP:

<https://blog.2ndquadrant.com/using-postgresql-tap-framework-extensions/>

Also easy to test database contents and emedded logic:

<https://www.slideshare.net/lembark/object-exercise>

Putting all or no logic into the database as a knee-jerk reaction
is usually a mistake. Especially with PG testing is easy using
extensions and schemas to segregate the code/data being tested.

At some point the data will have to hit code, especially in ETL or
reporting logic. Balancing the work in and out of the database
just makes sense. Which is probaly why it doesn't happen...

--
Steven Lembark 1505 National Ave
Workhorse Computing Rockford, IL 61103
lembark(at)wrkhors(dot)com +1 888 359 3508