| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Database programming standards
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'.
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Thu Jun 03 2004 - 10:51:50 CDT
 |
 |