On Mon, Aug 15, 2011 at 7:50 AM, Andreas Joseph Krogh
<andreak@officenet.no> wrote:
> Sorry if I stepped on any toes here. But seriously - by my definition of app-server PG is not suited at all. I
stronglywould discourage anyone from using any RDBMS as an app-server. *IMO* it makes development, testing,
separation-of-consern,debugging and re-deployment a nightmare.
>
> PG has a lot of nice DB-features and I use it every day, but as an app-server - no way.
>
The key issue here IMO is what you really want in an app server, which
is why my answer is "kinda." PostgreSQL can do, and do well, a strong
subset of what an app-server does. It is not a reasonable replacement
for a standard middleware solution with all the bells and whistles,
however.
This being said, you could build an app server around PostgreSQL where
Pg is the entry point of the app server without a whole lot of
additional problems. Want to send an email? Write the data to a
queue table and NOTIFY...... Let another process pick it up and
handle it. And the approach you have to take is different from a
traditional app server approach, largely because of the separation of
concerns issues you flag.
In general, as with any multi-tiered application (and several tiers
can exist within PostgreSQL quite well), separation of concerns is a
critical aspect of design. I'd suggest that PostgreSQL can do at
least half of what folks usually expect from middleware by itself and
do it well, without other processes listening for notifications. For
example, it can accept business logic calls, take the data presented,
manipulate (and store/retrieve), and send the updated data back to the
client, all while enforcing security and data integrity constraints.
Practical experience suggests that this is a solid majority of what a
middleware program is actually doing. And it can do things better
because you don't really have to deal with all the ORM stuff that
usually ends up in that environment.
If you want to do stuff beyond that, it is really best to either do it
before hitting the database (through the client or some lightweight
middleware wrapper), or after (via helper programs and NOTIFY/LISTEN
commands).
I think using PostgreSQL as a business logic entry point is not
necessarily a bad idea, provided the application is well designed.
The idea of using it to connect to other databases however, is
generally best avoided (though there are some cases where it is
impossible to do otherwise).
Best Wishes,
Chris Travers