On Mon, Aug 15, 2011 at 7:50 AM, Andreas Joseph Krogh <andreak@xxxxxxxxxxxx> wrote: > Sorry if I stepped on any toes here. But seriously - by my definition of app-server PG is not suited at all. I strongly would 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
