Re: "We don't do triggers"

"Peter Connolly" <peter_at_alum.wpi.edu> wrote in message news:39fde041.0311250644.332d9a04_at_posting.google.com...
> "Niall Litchfield" <niall.litchfield_at_dial.pipex.com> wrote in message
news:<3fc10fe1$0$7363$cc9e4d1f_at_news.dial.pipex.com>...
> > "Peter Connolly" <peter_at_alum.wpi.edu> wrote in message
> > news:39fde041.0311211053.7887c44a_at_posting.google.com...
> > > 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. In an n-tiered system, all business logic should be
> > > on the application server, not in the GUI or the database.
> >
> > I really, really don't understand this. Perhaps you could elaborate?
>
> In any 3+ tiered system, there is a GUI (i.e. web server + client), a
> backend to store data (i.e. database, LDAP, etc), and an application
> server to implement the business logic. See my previous posting for
> examples.

I understand n-tiered systems, I dont understand the sweeping statement that ALL business logic MUST exist in one place.

> sqlloader doesn't load EDI or XML, but I'm sure it would go much
> faster if it did.

sqlloader will load XML...

> Regardless, the vb.net system accepted all
> different formats (EDI, XML, csv) and all were passed through the same
> logic to load into the database. Have you ever tried to read an 8
> level nested EDI document with a stored proc? Its near impossible.
>
> >
> > > All data would be scrubbed and validated
> > > the same way. I've seen too many databases that have
> > > dirty/inconsistent data due to heterogenous data sources (i.e. five
> > > different ways to calculate taxes and split pennies). Performance is
> > > always second place to correctness.
> >
> > So these databases where did they calculate the tax and split the
pennies?
> > Pound to a penny it was in some app.
> >
>
> No, it was in 5 apps populating a few different databases. These 5
> apps each had their own methods of calculating how to split pennies.
> Some of them used stored procs to do it. Are you saying that pl/sql
> and triggers are not part of an application if they are used? Are they
> inherently part of the database simply because they are packaged with
> Oracle?

No I wasn't saying that db code isn't part of the application (though one might argue about referential integrity constraints etc). My point was that how to calculate tax, do rounding etc is app specific - the fact that the data is inconsistent has nothing to do with the data being stored in 5 different databases and everything to do with the business logic being different in each case. Doing validation in the middle tier or in the database won't do anything for this issue.

-- 
Niall Litchfield
Oracle DBA
Audit Commission UK