Re: "We don't do triggers"

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
[EMAIL PROTECTED]
(replace 'x' with a 'u' to reply)