Re: Implementing "thick"/"fat" databases

On Sun, Jul 24, 2011 at 12:51 AM, Chris Travers <chris(dot)travers(at)gmail(dot)com> 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