Jim Nasby wrote:
> I do a lot of work on systems where it would be impractical or
> impossible to do everything through middleware. The other issue is that
> you have to be very, very careful how you do integrity checking in the
> middleware if you want to avoid things like race conditions. The
> database not only gives that to you for free, but it's also extremely
> efficient at it.
Data integrity in the data just seems to make sense on the face of it.
Consider enterprise databases, with many different applications accessing any
given database, some of which reside outside the hosting enterprise. It is
unreasonable if not impossible to route all such applications through a single
(choke-) point on the way to the database, another single point. As Jim says,
enterprise-scale DMBSes are good at handling this sort of load.
> Perhaps if you carefully hand-code your middleware... my experience is
> that things like Hibernate tend to destroy performance because unless
> you really, really know it well you end up with some pretty bad database
> access methods. It doesn't have to be that way, but it often is.
I've seen similar difficulties with OO-relational frameworks.
The trap of such a framework is that getting to "really, really know it well"
requires at least as much database expertise as without the framework, plus
you have to know the framework even better. Even then you still often "end up
with some pretty bad database access"; best case is you get a subset of the
database system's power for an increase in application complexity. This is the
irony lost on the proponents of these frameworks: "If you work really, really
hard it'll save you effort, except in development or maintenance."
--
Lew
