Re[2]: Database programming standards
- From: Peter Robson <pgro@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Fri, 4 Jun 2004 09:45:54 +0100
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@xxxxxxxxx
*********************************************************************
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
----------------------------------------------------------------
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:
- » Re[2]: Database programming standards
