| 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[2]: Database programming standards
Very interesting discussion. Can only endorse 100% points made by Dan
in his message beginning ("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..."). I too disagree profoundly with the
view of his 'expert'.
Deen raised the key question:
> 3) Keep the Business logic in the database using stored procs and packs
> where ever possible to reduce network traffic and to ensure business rules
> are always enforced.
> I want to know from all of you out there: what are the reasons/arguments
> developers have against #3
... to which the answers have been essentially practical. The real reason to follow rule 3 is theoretical. (To indulge in semantics - theory is the precursor to good practice - practice without theory is flawed...)
The data held in an RDBMS is a model subset of the real world. That model DEMANDS definiton, and that definition is provided by the strictures of the relational modelling paradigm. To apply that methodology, and then separate the logic of the methodology from the data storage, when the rdbms by definition supports the tight coupling of the data with the model definition, is really quite illogical. Without this close coupling, one could never validate the correctness of the model without going outside the model, which is to ignore all the benefits that rdbms brings over the older systems. If you want more on this - see writings of C.J.Date etc.
Yes, some of our developers have tried to build logic into their applications. Why? A combination of the 'hacker' mentality, and the 'not invented here' syndrome, or 'I know best'. They get very short shrift now.
With the business logic embedded within the database, that environment does become immune to the changing application world. Who knows what new program environment M'Soft will next introduce ('.not'??) - at least with the model built in a coherent fashion, complete with all constraints within the database, application independence is achieved.
Final point - Dan's expert regarded that the database "was for storing data...only for storing data". OK, but define data. Having worked on our data architecture for years, I rapidly reached the conclusion that data can be divided into three components, all of which are candidates for storing in the database: 'Data' (as generally accepted), 'Documentation about the data, eg Metadata', and the means to access the former two - eg 'Application Code'. Each depends on the other, whichever way you look at them. So far I have comfortably achieved two out of three - the third is coming along nicely!
peter
edinburgh
mailto:pgro_at_bgs.ac.uk
*********************************************************************
This e-mail message, and any files transmitted with it, are
confidential and intended solely for the use of the addressee. If
this message was not addressed to you, you have received it in error
and any copying, distribution or other use of any part of it is
strictly prohibited. Any views or opinions presented are solely those
of the sender and do not necessarily represent those of the British
Geological Survey. The security of e-mail communication cannot be
guaranteed and the BGS accepts no liability for claims arising as a
result of the use of this medium to transmit messages from or to the
BGS. . http://www.bgs.ac.uk ********************************************************************* ----------------------------------------------------------------Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 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 Fri Jun 04 2004 - 03:52:09 CDT
 |
 |