Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: "We don't do triggers"

Re: "We don't do triggers"

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Tue, 25 Nov 2003 10:51:44 -0800
Message-ID: <1069786336.754140@yasure>


Peter Connolly wrote:

> Are you saying that pl/sql developers are better than java developers?

When it comes to databases and data integrity ... YES!

> There is no reason to believe that using pl/sql or triggers is any
> more effective than java in terms of data corruption.

True if you know little or nothing about databases but untrue in every

other venue. You write all the data integrity you want into your 
application. You give me two minutes in SQL*Plus. You can even have use 
a stopwatch. You'll have no data integrity when I get done.

   Last time I
> checked, pl/sql still couldn't use full regular expressions to
> validate data.

Regular expressions are irrelevant to data integrity. Thank you for making my point.

Data integrity is guranteed by primary key, unique, referential, and check constraints.

But FYI regular expressions are in Oracle 10g.

   Regardless of how it is implemented, a developer must
> code it.

And regardless of who codes it the person must understand relational rules and how integrity is enforced. Something that, based on what you have already written in this post, would give you a failing grade in my class.

   I've seen just as many bad pl/sql developers as java
> developers.

I've seen more. But only because I see more of them. But good Java code does not have anything to do with good database skills.

   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

Good.

> Object-oriented

Good in some situations and poorly performing in others.

> Vendor independent

Total nonsense. Absolute total nonsense. Anytime you try the same solution against Oracle where reads don't block writes and writes don't block reads and then try the same solution against DB2, Informix, Sybase, or SQL Server you'll likely discover what a crock this is.

> Flexible (can talk to almost *any* other system: LDAP, doc
> repositories, etc)

Put the emphasis where it belongs ... on the word ALMOST.

> Can provide data in any format (http, web-service, xml)

So can PL/SQL ... so what.

> ...
>
> Advantages to PL/SQL:
>
> Better performance

Amen. Add to that more scalable and more secure.

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

Double-talk. What does "that your dba controls" mean in English? You've got production Oracle databases managed by chimpanzees somewhere? (Ok folks don't respond to that hyperbole ... I already know what you're thinking.)

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

You are writing a lot of words but not one of them has anything to do with data integrity, scalability or security. I guess these issues just don't matter to someone that is front-end-centric.
>

>> In an n-tiered system, all business logic should be >>>on the application server, not in the GUI or the database.

According to what authority?

>>According to who. I want names, dates, and places. This is pure 
>>unadulterated garbage.
>>

>
> According to everybody.

Nice dodge. Please note that I teach computer science at a university. I am quite well aware of the religious zealots and advocates for just about everything. But you'll not find anyone that has a serious understanding of relational databases that will support your contention.

You want to move gigabytes of data across a wire to another machine to perform functions that could be done in-place. You want databases that can be corrupted by anyone that can access them with any tool other than your front-end via your app server. You want to kill performance, scalability, and security over some desire to meet some theoretical standard written by someone that cares nothing of these either. You'll not find many people supporting your proposition with a serious understanding of the issues.

I have worked on projects where this was done. The only ones that have been successful have involved very large organizations with very good procedures in-place to enforce through management what isn't enforced through the database.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)
Received on Tue Nov 25 2003 - 12:51:44 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US