James B. Byrne wrote:
> I am considering moving
> theses sorts of purification routines into the DBMS because I feel that is
> where they really belong. However, the prevailing sentiment of the community
> surrounding Rails seems to hold otherwise so I wonder if this is really the
> right thing to do.
>
They also like to use simple, dumb, unsafe databases that're really fast
for simple queries.
Many web apps consider the database their private stomping ground - a
more covenient and faster way of storing tabular (but not necessarily
even truly relational) data than flat files. They often seem to shun
powerful SQL and the use of data structures that can also be understood
and used by other applications.
I suspect some of this grew out of the primitive OSS databases available
when a lot of the big open source web apps got going, and it's thinking
that's become rather prevalent in the community.
I could understand it if database portability was a goal, because then
you really do often want to keep things as dumb as possible. I guess the
ones that aren't seeking database portability must be trying to still
work on MySQL 3 & 4 , which means "use as few database features as
possible".
To me it seems obvious that such routines should be in the database, but
I guess that's partly because of the sort of work I'm doing. Other apps
can then use the in-DB routines, rather than having to reimplement them
(read: fewer things to test and debug) . They can be cached intellgently
by the DB server and taken account of in query planning. The DB can help
intelligently manage concurrency. Db<->client round trips may be
reduced. For simple immutable functions you can rely on them being
available for any database you'd actually care to use.
Then again, that kind of thinking is part of why I'm not much of a fan
of SQL-abstracted web app frameworks.
--
Craig Ringer