Re: Database programming standards
- From: Daniel Fink <Daniel.Fink@xxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Thu, 03 Jun 2004 09:53:57 -0600
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. First, for performance reasons, data
manipulation performed at the database layer should perform better. Second,
when the rules are enforced in the database, the development staff does not
have to remember to include them in the code, which someone always forgets or
misunderstands. Finally, when we are called to troubleshoot performance/data
issues, having the rules in the database where we can get to them (extracting
constraints/triggers/procs is pretty straightforward) makes the dba job
easier. I've found that most of the time, the application development teams
rarely document and understand what can be done when this problem arises.
I just had a conversation with a developer about the same kind of issue. After
a long discussion, I recommended that they not use stored procedures and kept
the data loading/validation in the app layer using java. In this case, they
needed to get the app through the development process quickly, performance is
not an option (at least at this point...I'm guessing this will change) and the
team knows java, not pl/sql. He is well aware of the performance
problems.
Cynically,
Daniel Fink
Niall Litchfield wrote:
> I came across a very similar question on usenet and posted the following
>
> <question>
> 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?
> </question>
>
> 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.
>
> Unfortunately the programmer types reading this thread considered that
> my suggestion was sensible and of great technical merit :(
>
> I wish you luck with your 'discussions'.
----------------------------------------------------------------
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:
