Re: Database programming standards
- From: Rachel Carmichael <wisernet100@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Fri, 4 Jun 2004 05:08:34 -0700 (PDT)
The best argument for keeping rules in the database itself is that this
way ensures that the rules then are consistently applied. No one can
circumvent the business rules by going directly into SQLPlus and making
data changes ("but it's an emergency change and we need it fixed NOW").
I'm dealing right now with a DBA who does that. Right now he's like a
rogue cop in all our databases. He's really good at what he does, but
he's got blinders on about some things (keeps insisting that a BCHR of
70% is "too low"). He does not tell anyone in the operations group (or
the other DBAs for that matter) what he is doing. And he's doing all
this in production. And then the rest of us get slammed for the
performance problems.
Then there's the 3rd party app, which has no constraints on it at all
so that it can be "database generic". We move the data to a new
application, homegrown, that HAS constraints (I'm the DBA, involved in
the design process, my rule is "it's my database, so it's my
rules")....
and I spend hours writing programs to clean up the data.
Blathering on here to make sure I don't get this thrown into "moderate"
state :)
Who cares about this stuff, it's Friday and I've got tickets to Harry
Potter for Sunday!
--- Nuno Souto <dbvision@xxxxxxxxxxxxxxx> wrote:
> Daniel Fink allegedly said,on my timestamp of 4/06/2004 1:53 AM:
>
> > Gosh, this sounds like a rather heated discussion I had with
> > an expert in the past. His position was that the database
> > was for storing data...only for storing data.
> > No RI, no check constraints, no stored procs, no triggers.
> > His argument was that anything related to business rules
> > belonged in the application layer. I have several problems with
> > this, aside from it being great theory which fails miserably in
> > practice.
>
> You're not the only one...
>
> Couple of minor questions for your duh-veloper: when another
> application
> sharing the same database has to use these rules in the app server,
> where does it get them from?
>
> No, an EJB CANNOT be shared between applications in J2EE.
> Applications
> in an EJB container run in DIFFERENT JREs and CANNOT share an EJB!
> No, Java communications are slow as a dog.
> No, .NOT is not any better in the same respect.
>
> How does the team ensure that the data integrity and business rules
> will
> stay the same if they now have to be maintained in TWO source bases,
> presumably by two disjoint development teams?
>
>
> > Cynically,
> > Daniel Fink
>
> You're not wrong.
> But I'm sure I'm gonna be the only one receiving hate mail from some
> idiot in outer Mongolia who is the new "God's gift" in all things
> IT, claiming I'm dispensing wrong advice...
> (care factor? Nill)
>
> --
> Cheers
> Nuno Souto
> in sunny Sydney, Australia
> dbvision@xxxxxxxxxxxxxxx
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
