Re: "We don't do triggers"

From: Volker Hetzer <volker.hetzer_at_ieee.org>
Date: Tue, 25 Nov 2003 18:28:40 +0100
Message-ID: <bq03ga$m6$1@news.fujitsu-siemens.com>

"Peter Connolly" <peter_at_alum.wpi.edu> schrieb im Newsbeitrag news:39fde041.0311242103.4017e449_at_posting.google.com...
> Are you saying that pl/sql developers are better than java developers?
I don't think the language is the issue, particularly since you can do triggers and stored procedures in java.

> > In an n-tiered system, all business logic should be
> > > on the application server, not in the GUI or the database.
> >
> > According to who. I want names, dates, and places. This is pure
> > unadulterated garbage.
> >
>
> According to everybody. The purpose of an application server is to
> contain business logic.

Actually that's the purpose of triggers and stored procedures. The purpose of an application server is to cost money, use up cpu time and create bandwidth and securoty problems.

> > If you
> > > can't write logic then your stored procs would be reduced to simple
> > > insert, update, delete, and select statements. Most J2EE application
> > > servers now support container managed persistence, which means it will
> > > handle all of the sql select and dml statements for you.
> >
> > And which means that the first person that goes into your database by
> > any means other than your specified front-end can do anything they wish.
> >
>
> Don't give out the password.

So, don't sell the app and go bust. Or rewrite the database in the appserver.

> The point of having a developer is to implement the business logic.
> Utilizing a tool that automates data access and transactions allows a
> developer to focus on only the business logic rather than struggling
> with becoming an expert at stuff a DBA already knows.
What has a developer to do with the dba?

> > Because using them is more scalable, more stable, more secure, and
> > perform faster and we sure as H... don't want any of those things in a
> > database application.
> >
>
> More scalable, stable and secure? Do you have proof?
Very simple: You've got an app with several clients all going through the appserver and the appserver then connects with one password to the db and does its stuff.
What happens?
1) you need another cpu for running the appserver. 2) you check privileges twice: oracle checks that the app server

    can do what it wants to do and the appserver checks that     the client can do what it wants. Much more efficient to check     only once. Where? Where the data is, of course. 3) databases are *made* for load. You can do RACs. DB companies

     have much more experience with this tnat others. Doing something
     RAC like with appservers requires to reinvent the wheel.

4) If the appserver checks business constraints he has to pull all

    relevant data across the network, check it and then do the action.     this wastes bandwidth.
5) To all those OOP guys: OOP was about putting data and

    functionality together in one place, right?

>
> Stored procedures are not flexible at all,
What do you mean?

> they are not
> object-oriented

1) So, java isn't object oriented? Tell me more about it. 2) OOP isn't a dogma. It's a tool, to be used when best

    suited for the job.

> and they have very limited ability to talk to other
> systems

Wrong.

> (can pl/sql call a web-service to get information?).
Yes.

Greetings!
Volker Received on Tue Nov 25 2003 - 11:28:40 CST