On 8/16/11 10:24 AM, Chris Travers wrote:
I can't let this slide :-D
On Tue, Aug 16, 2011 at 9:27 AM, Evan Rempel<erem...@uvic.ca> wrote:
Technically it can be done, but just because we can do something does not
mean we should do something. Having said that...
We have been using a middleware product that shall remain nameless,
that goes against a large commercial database that shall also remain
nameless.
The middleware has been migrating to a more and more database based code
set, and as an administrator of such a system I can state that this is
awful.
> From your description below, it truly sounds awful. However, this
strikes me as being an issue of *which* logic is moved into the
database instead of *that* logic is being moved into the database.
In other words, it's just a typical engineering problem: pick the right tools
for the job. Just because you're a good mason doesn't mean you should build a
boat out of cement. You can do it, but aluminum, steel, fiberglass and wood
are better choices. Just because you are really good at database programming
doesn't mean you should turn a database server into a web server. You can do
it, but it will be an expensive, suboptimal, and unmaintainable system.
There are many opinions about the exact right balance of where functionality
should be implemented, but extreme solutions are almost never optimal.
Craig
Getting appropriate logging out of the application logic for both auditing
purposes
and trouble shooting is near impossible. Performance is nearly impossible to
tune as
everything runs inside the database. One giant process chewing up cores of
CPU power.
LedgerSMB has been moving in the direction of more logic in the
database because we have found the opposite. Troubleshooting is
easier, code maintenance is easier, performance is easier to
troubleshoot and manage, and security is far more manageable. Now,
granted we are retrofitting security onto a codebase which had none
when we forked, so that is a difference..... We have eliminated a
much larger number of bottlenecks by going this way than we have run
into. Again the issue is *which* logic goes into the db, and that's
an absolutely key question when running middle tiers in the dbms.
Security is near impossible to manage as well. Again, almost everything
needs to run as
the same user. The database is now making calls to generate pdf objects and
make
printing calls.
Ouch.... I guess I could kinda see the PDF generation calls (I'd still
prefer a queue and transform approach), but not the printing calls.
And if you can't move security into the database, then you have a kind
of major problem: you aren't *really* generating a consistent and
consistently enforced API in this way, and so you can't get to the
roles a middleware solution gives you.
As long as you still need the middleware, then the question really
becomes, what logic needs to be centralized in the db and what logic
is specific to each middleware application? What do you get from
putting each thing in the database? My recommendation is to review
that. If it is a single app db, then use stored procs as essentially
named queries. If it is possible, move the printing calls into a
separate process and have it signalled by the db app on database
commit.
But it really sounds like an unmaintainable mess. IME, however, that
is avoidable while still placing the RDBMS in the center of the
logic-complete application server environment.
None of the traditional tools can be used to integrate the application into
the enterprise.
The load balancer needs to add x-forwarded headers to http requests, but the
custom http code can't handle that, so all web access appears to come from
the load
balancer. This violates regulatory requirements. Log file formats are not
standard
since none of the code is standard, this means that none of the event
correlation
tools can be used for intrusion detection etc.
Ouch..... I second the suggestion that the architecture here lacks
the separation of concerns approach necessary to make this work, and
that either the software you are using is the problem or the architect
is. However, it doesn't tell me that the approach of using the RDBMS
as the entry point into an application server environment is
necessarily a bad thing.
Best Wishes,
Chris Travers
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
