From oracle-l-bounce@freelists.org Fri Jun 4 03:52:09 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i548psE12395 for ; Fri, 4 Jun 2004 03:52:04 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air189.startdedicated.com (8.11.6/8.11.6) with ESMTP id i548pi612357 for ; Fri, 4 Jun 2004 03:51:54 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 7576272D731; Fri, 4 Jun 2004 03:38:09 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03600-94; Fri, 4 Jun 2004 03:38:09 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 3B76272D72B; Fri, 4 Jun 2004 03:33:30 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Fri, 04 Jun 2004 03:31:38 -0500 (EST) X-Original-To: oracle-l@freelists.org Delivered-To: oracle-l@freelists.org Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 2E23472D6C6 for ; Fri, 4 Jun 2004 03:31:37 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02100-36 for ; Fri, 4 Jun 2004 03:31:36 -0500 (EST) Received: from mhp010.nerc-murchison.ac.uk (mhp010.nerc-murchison.ac.uk [192.171.157.135]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 4A00472D6C4 for ; Fri, 4 Jun 2004 03:27:24 -0500 (EST) Received: from mhntsmail.ad.bgs.ac.uk (mhntsmail.ad.bgs.ac.uk) by mhp010.nerc-murchison.ac.uk (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Fri, 4 Jun 2004 09:51:18 +0100 Received: from mhp433.ad.bgs.ac.uk ([192.171.142.191]) by mhntsmail.ad.bgs.ac.uk with Microsoft SMTPSVC (5.0.2195.6713); Fri, 4 Jun 2004 09:45:54 +0100 Date: Fri, 4 Jun 2004 09:45:54 +0100 From: Peter Robson X-Mailer: The Bat! (v1.62r) Personal Organization: British Geological Survey X-Priority: 3 (Normal) Message-ID: <766749895.20040604094554@bgs.ac.uk> To: oracle-l@freelists.org Subject: Re[2]: Database programming standards In-Reply-To: <200406040552.i545qEqx009531@smtp-out3.xs4all.nl> References: <200406040552.i545qEqx009531@smtp-out3.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 04 Jun 2004 08:45:54.0770 (UTC) FILETIME=[59150B20:01C44A10] X-Virus-Scanned: by amavisd-new at freelists.org X-archive-position: 1958 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: pgro@bgs.ac.uk Precedence: normal Reply-To: oracle-l@freelists.org X-list: oracle-l X-Virus-Scanned: by amavisd-new at freelists.org 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@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 ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------