Re: Oracle DK2000 Three-tier client/server?

In article <Dxzn2p.AGL_at_ireq.hydro.qc.ca>, Michel Lapierre <milapier_at_ge.hydro.qc.ca> wrote:
>guru_at_guru.nir (Bemused by Oracle) wrote-écrivait:
>
>>Oracle claims that DK2000 can deliver 3-tier client/server systems. I
>>believe that the only way that they can make this dubious claim is by stored
>>procedures and their lame PL/c interface with stored procedures. Or is
>>there something that I missing?
 

>>Oracle is a two-tier, non-messaging middleware client/server tool. As long
>>as you can stay within their environment, it's great. If you need
>>architecture outside of Oracle -- bummer. Agree?
>
>Yes you can be in one form of 3-tier by doing stored procedures and
>removing a lot of natural fonctionnality from FORMS like the base
>tables, lov.
>
[snip]

Well, one can argue that this is some FORM of 3-tier, but this is really just two-tier, with the database tier able to handle some logic. Oracle does do a good job in allowing multiple database servers to work together, so you can get some of the advantages of three-tier, but you also start hurting your database. In other words, you get something of an extra tier by hurting another. Not ideal, though in some cases worth it. So Oracle does have SOME basis in making a claim that their SERVER supports three-tier to a degree.

Plus, if you keep it all from one vendor, you don't have to worry about finger-pointing as much (of course, you first have to get through to Oracle, so this might not help ... ;-> )   

True three-tier architecture will give you alot of advantages the above will not. You really need messaging, reliable queueing, load balancing, etc. You want to be able to have services live on lots of computers, and not necessarily on your database server. You want to be able to pass messages between services and services and clients and clients without hitting the database. One of the big ideas behind 3-tier is to take some logic OFF your database, as well as OFF the client, and let it live anywhere it wants (or needs to be).

It is best to have your database server be a database server, and not burden it with extra connections and code and threads to handle stuff that should be handled by other machines or logic.

Good luck,
Mark McNulty
JYACC Consultant
mmcnul_at_jyacc.com

Note- these views are mine and not those of JP Morgan or JYACC. Received on Thu Sep 19 1996 - 00:00:00 CEST