Re: choices regarding where to place code - in the database or middletier

From: Sudsy (bitbucket44_at_hotmail.com)
Date: 01/21/04 

Date: Wed, 21 Jan 2004 10:42:41 -0500

Noons wrote:
<snip>
> Minor correction: two-tier client-server is dead. Multi-tier is STILL client-server!
> Not that I agree: now that we finally have the gear (CPU and memory) and network
> bandwidth to make two-tier viable, what does this industry go and do? It kills it.
> Brilliant...

I suppose that I'd have to be labelled an n-tier advocate. Interesting
that your viability argument, namely "the gear (CPU and memory)", is
equally applicable to n-tier.
Try to look at the situation from different prespectives. Suppose you
have a company which run P****ess. They've spent years creating their
"trigger" code using the proprietary programming language (stored
procedures didn't exist on the platform until a few years ago).
Now the business has grown to the point where P****ess represents a
liability. Too many problems, too much hands-on required for what
should be fairly basic operations. They'd like to upgrade to Oracle
but they're stuck: it would take man years of effort to rewrite the
archaic and "magical" trigger code in PL/SQL.
Or how about a small company which selects MySQL simply because it's
so cheap? (Free, actually.) A little while down the road and they
find a need for the features (on-line database backups, available
24x7) provided by an "enterprise" RDBMS like DB/2 or Oracle. If they
implemented the business logic in the middle tier then the back-end
becomes plug-and-play.
Portability is important to me, and should be for most organizations.
Tying yourself to a single vendor can severely limit your options.
Think about technologies like XML. Any computer which can read and
write text files and provides network interfaces can exchange XML
documents with any other computer without regard to architecture,
operating system, etc. Gone are the days of complicated record
structures and painful conversions.
I'm just advocating a similar approach to application design.

Relevant Pages