Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: choices regarding where to place code - in the database or middletier
Daniel Morgan wrote:
> Joe Weinstein wrote:
>
>> However, that dbms-specific level should be as narrow and >> controllable/switchable >> as possible. J2EE standards help there. >> Joe >> >>> Just my 2 cents >>> >>> Daniel
cool.
> The 'lets push more bytes down the pipe and across all those routers'
> thinking is not going to lead to performance. You may be scalable but
> performance will suffer. And you will be no more scalable than a thinner
> client.
Well, I actually want thin clients, but from DBMS perspective, the application server is not a thin client. I do believe that no bytes should leave the DBMS that aren't needed at the end client, but once they've left, they should be retained and milked/reused for all they are worth, and this can be intelligently and profitably done. Performance and scalability follow, according to the nonvolatility of the data, the relative proximity of the clients to the middle tier as opposed to their distance to the DBMS, and the relaitve lightness of the communication protocol between client and middle tier as opposed to the protocol between DBMS and any of it's clients.
> Render under to database everything you can do in the database and let
> the middle tier do what it does best ... fail-over, load levelling, and
> serving up the front-end.
Sure, and protecting the DBMS from uncontrolled ad-hoc connections and mindless repeat queries, and acting as a transaction monitor/controller to get the best performance out of the DBMS, etc. Otherwise you should explain why Oracle chooses to use BEA as middleware when it simply tries to demonstrate it's own performance potential in TPC-C benchmarks.
> Try tuning all that rotten SQL coming from those fat front-ends sometime
> and you will understand why those here that have experience with
> PeopleSoft, SAP, Baan, and Siebel are remarkably unhappy.
Well, sure. I have done so, in fact. The stupidities are legion. Many of these
applications are ridiculous 'ports' of 70's era COBOL/ISAM applications to
'client-server' by simply swapping in row-by-row cursor fetches to the DBMS
instead of the previous ISAM call. Intelligent client-server architecture
(as I've said) puts the sawmills where the trees are, not in the client. However,
client-server is dead, at least to the extent that now everyone in the company
or the internet may want the info in the DBMS(s), and transactions now involve
serveral DBMSes and other resources. Thats where the middle tier makes it's
contribution, and depending on what's done, and what degree of concurrency,
isolation, atomicity etc that particular data requires, it can now find a
profitable home in either the DBMS or the middle tier, at least as a cache.
As an example from the Baan suite, they really did architect their application
so it queried the DBMS for a list of the countries in Europe hundreds of times
a day for each user. A current state-of-the-art application would have a generic
browser as one of it's clients, and in such a case, the middle tier is ideal for
caching the list of the countries in Europe, and making is available to all
clients, and given the political instability in Europe, maybe refreshing it's
list once daily from the DBMS? It saves a lot of DBMS cycles...
IMHO...
Joe
Received on Tue Jan 20 2004 - 18:28:05 CST