Re: "We don't do triggers"

Daniel Morgan <damorgan_at_x.washington.edu> wrote in message news:<1069449434.96746_at_yasure>...
> Comments in-line.
>
> Peter Connolly wrote:
>
> > In addition to portability, another reason for specifying no stored
> > procedures could be to ensure that there is no business logic in the
> > database procs.
>
> Because you value data corruption?

Are you saying that pl/sql developers are better than java developers?  There is no reason to believe that using pl/sql or triggers is any more effective than java in terms of data corruption. Last time I checked, pl/sql still couldn't use full regular expressions to validate data. Regardless of how it is implemented, a developer must code it. I've seen just as many bad pl/sql developers as java developers. What it really comes down to is: which is the better way to implement it, in a J2EE server or Pl/SQL.   

Advantages to J2EE:
Portable
Object-oriented
Vendor independent
Flexible (can talk to almost *any* other system: LDAP, doc repositories, etc)
Can provide data in any format (http, web-service, xml) ...

Advantages to PL/SQL:

Better performance
May be quicker to implement as SQL is a 4GL. Can talk to any other Oracle system (that your dba controls)

If you don't need any of java's advantages then it doesn't make sense to buy a J2EE server. But for most enterprise applications, it makes a lot more sense than using PL/SQL to contain business logic.

>
> 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. see www.whatis.com: http://searchdatabase.techtarget.com/sDefinition/0,,sid13_gci211584,00.html

You must not have been paying attention in class either, I found several links from your school's web site either quoting or eluding to the fact that an application server handles the business logic:

http://www.ischool.washington.edu/mcdonald/courses/info341_wi03/Lecture-11.dist.arch.pdf (page 12)

http://www.washington.edu/slo/technology.html (last paragraph describes MVC architecture)

Even your school's pre-meds understand the concept: http://icsl.ee.washington.edu/class/ee400b/notes/webtech.pdf (page 2)

> 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.

> That leaves
> > very few cases when an application developer on an n-tiered system
> > will need to write a stored proc.
>
> Which they don't want to do because doing so would expose their
> incredible lack of knowledge to public view. They haven't a clue about
> concepts, they haven't a clue about architecture, they wouldn't know an
> atomic transaction data model from an atomic bomb if it was sitting on
> their dining room table. If ignorance is bliss ... then this has got to
> be a first-class ticket to the garden of eden.
>

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. If a developer is required to be as smart as the DBA when it comes to databases then why have a DBA?

> I think there is still a place for
> > stored procs, but they should be used sparingly in an application like
> > this.
>
> 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?

Stored procedures are not flexible at all, they are not object-oriented and they have very limited ability to talk to other systems (can pl/sql call a web-service to get information?). This makes it a less than ideal choice for a real enterprise system.

> Thank you for providing me with classroom material. It is just the kind
> of thinking that makes the perfect bad example. It is thinking like this
> that is resulting in so many failed IT projects and so many jobs being
> off-shored. All fluff ... no substance.

If this is a bad example, could you please give me a good example? Does it involve an application server? If so, then what role does it play? If an application server does not contain business logic then what does it do?

Before using this for "classroom material" you may want to get your facts straight by talking to your professor Mcdonald whom I link to above. He says: "Server between client and backend is known as the application server, it handles the 'business logic'."

-Peter Received on Mon Nov 24 2003 - 23:03:08 CST