"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. 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
> > |
> > |
You miss the point, Peter. By putting it in the backend (the database) then
you don't have to write it multiple times! You put the business rules in
the backend and then multiple front and middle tiers can all use the SAME
business rules. It has nothing to do with J2EE. J2EE is just another
language; it does not change best practices of putting the business rules
close to the backend to ensure data integrity, consistency etc. In evitable
by putting it in the middle tier you make data integrity a hard thing to
administer. People who need to use the data, load, etc. will go around the
application server due to "Internet Time", lack of resources, etc. claims
and deal directly with the database and thus avoid the business rules. (now
potentially corrupting the data, making the following of business rules
harder (code it again, QA is yet again)) We have been down this road, we
have solved this problem, ignorant high priced incompetent consultants are
not an excuse.
Jim
Received on Fri Nov 21 2003 - 13:42:52 CST
