On Sun, Jul 24, 2011 at 12:51 AM, Chris Travers <chris.travers@xxxxxxxxx> wrote: >> I was thinking similar thoughts, but you not only beat me to it, you made >> some good points I had not thought of! >> >> The only thing I can think of adding: is that it would be good to lock down >> the database so that only the middleware can access it, everything else >> accesses the database via the middleware. > > In general, I am not convinced that middleware is inherently more > maintainable than in-db procedures. exactly. procedural middlewares written in languages like java tend to be bug factories: *) over-(mis-)use of threads *) performance wins moving logic outside the database to scale it are balanced out by the extra traffic *) database concurrency issues *) OO representation of data is brittle and inflexible *) extremely (and IMNSHO unnecessarily) verbose *) framework all over the place *) libraries all over the place On the plus side though, languages like java have huge pools of available talent and excellent tools. These factors are *critical* for many IT companies. plpgsql may be the bee's knee's (it is) but DIY tools and methodologies tends to translate directly to a high cost of labor, and application developers used to rich tool environments tend to really dislike code practices that pl/pgsql requires like debugging by logging and remembering where stuff is and what it does. plpgsql is a niche language that tends to attract the same really smart people who write code in a more functional style. When done well, you can do a lot with a very small amount of code. I would love to see stronger validation features (with a higher emphasis on warnings) and better tools/editors to help bring plpgsql to the mainstream. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
