Re: "We don't do triggers"

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 Fri Nov 21 2003 - 12:53:06 CST