Andrew Sullivan wrote:
> This is why many applications that have some portability layer for
> the database seem to be so awful at using the database: they can't
> use any of the strengths of any of the underlying databases, because
> those strengths are usually the thing that some other database is
> really bad at. So you often end up with an application that isn't
> truly stellar at anything, and your database system has to be
> oversized to perform acceptably. (Note that there's nothing
> intrinisically wrong with this approach; you've just optimised your
> code for portability at the expense of performance.)
Yup, the tend to heavily rely on data integrity management on the middle
tier. Which by the way is not totally crazy, because you need most of
the data integrity rules on the frontend anyways, to generate proper
GUI's. Actually in non object-relational RDBMS (which are the norm,
PostgreSQL is special), you can never do your full integrity management
inside the database. Which is all kind of ok, as long as you never mess
with the database through anything but your single middle tier
implementation.
My point is, there are solid reasons for writing applications that use
the database as a mostly stupid data store with very efficient retrieval
and these applications tend to also perform pretty well regardless of
what RDBMS you stick underneath.
regards,
Lukas
