From: Steven Lembark <lembark@wrkhors.com>
To: pgsql-general@lists.postgresql.org
Cc: lembark@wrkhors.com
Subject: Re: Rationale for aversion to the central database?
Date: Sat, 28 Apr 2018 10:16:53 -0500
Message-ID: <20180428101653.5706d3e7@wrkhors.com> (raw)
In-Reply-To: <20180428013651.dmsbdk4rxp7l6xoa@raf.org>
References: <7e56cc47-ae9c-43ee-9984-77df3a485d2e@Spark>
<20180427095537.65a682bc@wrkhors.com>
<8E2D0CF9-539A-4AA7-AF23-B206716134F2@ci.stpaul.mn.us>
<20180428013651.dmsbdk4rxp7l6xoa@raf.org>
> 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@wrkhors.com +1 888 359 3508
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-general@postgresql.org
Cc: lembark@wrkhors.com, pgsql-general@lists.postgresql.org
Subject: Re: Rationale for aversion to the central database?
In-Reply-To: <20180428101653.5706d3e7@wrkhors.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox