Re: "We don't do triggers"

On 21 Nov 2003 10:53:06 -0800, peter_at_alum.wpi.edu (Peter Connolly) wrote:

>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.
>

So they have made you believe the usual crap. Business rules should be in the database *CENTRALIZED*. If you can't write stored procs you will be probably incapable to get it working properly using the latest Java crap. Or do you want to forbid everyone to use direct interfaces? Don't you think they sooner or later will *have* to be used, just *because* of your 'smart' n-tiered system?

>
>>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.
>

Just another piece of bullshit. Using native dataloads is usually in order of magnitudes faster than your EJB bullshit and it is in order of magnitudes more stable. Most people using EJB also don't care about performance and don't care about referential integrity because they believe they have referential integrity enforced properly through the shitty app. Needless to say in that case there is also no correctness and disaster will strike sooner or later.

>>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
>

Exactly! So where should the logic reside? IN THE DATABASE, AND NOWHERE ELSE.
Please stop spreading your bullshit fairy tales. Your approach is a nightmare for everyone, end-users and dba's alike, but above all for dba's, because they have to sort out the mess your bullshit approach has inflicted upon them.

--
Sybrand Bakker, Senior Oracle DBA