Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re[2]: Database programming standards

Re[2]: Database programming standards

From: Peter Robson <>
Date: Fri, 4 Jun 2004 09:45:54 +0100
Message-ID: <>

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!



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

Please see the official ORACLE-L FAQ:

To unsubscribe send email to: put 'unsubscribe' in the subject line.
Archives are at
FAQ is at
Received on Fri Jun 04 2004 - 03:52:09 CDT

Original text of this message