Re: "We don't do triggers"

There seems to be a fundamental issue being talked around.

What constitutes an "application server"? And since when are triggers and procs not considered a good place for business logic? And I don't care whether you use Oracle or SQLServer or whatever.

The issue was getting business logic off of the client. That's where this all started. Whether it's in an app server or in the database is a secondary issue. We got it out of the client, where it never belonged.

It seems to me that there are those that rather than being concerned with *application servers* are more concerned that the business logic code be "portable", i.e. J2EE vs. any particular stored procedure language.

The fundamental advantage of app servers in realilty been in terms of platform, not in terms of business logic deployment. In that regard it's almost as bad as client-based business logic.

We could have had portability on the client, but what would have been the point?

I make almost the same argument with portable app servers. App servers are best at preparing pages for users. They are a weak place (IMHO) to place business logic. It again makes the DB vulnerable. Your data is your asset, not your logic. Logic changes, data once recorded should not, given a static storage model.

What this means is no matter the DB you code the major portion of the logic in stored procedures and triggers. You might argue that we now need correct/better OO database triggers and procedures. I'm with you. But get the business logic as far away from the client as possible, when possible. You can put it in the app server, but then you've made the data less secure.

Having written all of that we here where I work do a terrible job with ref integrity. ;)

Greg   

In the end you can have

peter_at_alum.wpi.edu (Peter Connolly) 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. 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. That leaves
> very few cases when an application developer on an n-tiered system
> will need to write a stored proc. I think there is still a place for
> stored procs, but they should be used sparingly in an application like
> this.
>
>
> >1. NO DATA LOADS EVER. Key it through the app ALWAYS. even 10 million
> > rows.
>
> I don't think data loads should have to be "keyed" through the app.
> If all data loads were required to use the application code (i.e.
> passing data to an EJB) to insert data that could be a very good
> thing, if it is feasable. 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.
>
> >2. NO INTERFACES TO OTHER SYSTEMS, EVER. make other systems talk to
> the
> > app.
>
> This could be a good thing too, for the same reason data loads should
> be done through the application. Why should a company pay for
> developers to implement the same logic multiple times?
>
> -Peter
>
>
> "mcstock" <mcstockspamplug_at_spamdamenquery.com> wrote in message news:<vKKdnWcJ8-NCsCOiRVn-ig_at_comcast.com>...
> > some take this stand for portability -- stored procedures must be written,
> > at least partially, in a proprietary language that is not portable across
> > databases
> >
> > so what's the target deployment environment(s)?
> >
> > --mcs
> >
> > "Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote in message
> > news:3fbe0e38$0$9392$ed9e5944_at_reading.news.pipex.net...
> > | "(Pete Cresswell)" <x_at_y.z> wrote in message
> > | news:q9lqrv4rdlcughil17flbbu2ln162bbu7r_at_4ax.com...
> > | > I'm on the periphery of a rather large (to me, at least: $10 mil..)
> project in
> > | > which the tech folks flatly say "NO STORED PROCEDURES: NONE, NOT EVER!".
> > | >
> > | > There's got to be a reason, but I don't know enough to even guess at it.
> > | >
> > | > Somebody?
> > | I'd ask. If the answer is all the logic etc belongs in the application
> > | explain that there will be 2 corollaries
> > |
> > | 1. NO DATA LOADS EVER. Key it through the app ALWAYS. even 10 million
> rows.
> > | 2. NO INTERFACES TO OTHER SYSTEMS, EVER. make other systems talk to the
> app.
> > |
> > | They both follow logically from this 'design' rule.
> > |
> > |
> > | --
> > | Niall Litchfield
> > | Oracle DBA
> > | Audit Commission UK
> > |
> > |
Received on Wed Nov 26 2003 - 15:21:27 CST