Jim Kennedy wrote:
> "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
>
>
What if you have customers that wish your product to run
on a variaty of backends?
Makes sense to put (1 version!) of the business rules in
the middle tier to me. Use the database just as a pool of data;
no logic
--
Regards, Frank van Bortel
Received on Wed Nov 26 2003 - 15:13:22 CST
