Re: Foreign key in Oracle Sql
From: DA Morgan <damorgan_at_x.washington.edu>
Date: Tue, 25 Jan 2005 07:45:56 -0800
Message-ID: <1106667802.693312_at_yasure>
>
> [snip]
>
>
>
> [snip]
> Interestingly, Oracle Apps does the same thing to some degree for a large
> majority of the underlying database - no primary keys, compensated for in
> large part by unique indexes (which are a different non-logical construct
> and behave differently than PK's), and no implemented foreign key
> enforcement. However, triggers are used.
>
> I imagine Oracle's reasoning for this architecture is relatively analogous
> to the lowest common denominator reasoning you mention that SAP adopted for
> its approach. I personally haven't seen an Oracle ERP Applications
> implementation on a non-Oracle DBMS, but an examination of their current
> implementations seems to imply a desire to at least have the capability of
> accomodating multiple vendor DBMS's.
>
> One mitigating factor that might prove to be superior to that of SAP or
> other ERP products is that a logical model (versus implementation) is
> available as part of a ERTM and these logical constructs are fully
> documented in an ERP application level data dictionary, the structure of
> which is virtually identical to the underlying DBMS data dictionary.
>
> - Dan
Date: Tue, 25 Jan 2005 07:45:56 -0800
Message-ID: <1106667802.693312_at_yasure>
Dan wrote:
> "Christopher Browne" <cbbrowne_at_acm.org> wrote in message
> news:35l9j3F4ohek5U1_at_individual.net...
>
>>After a long battle with technology, DA Morgan >><damorgan_at_x.washington.edu>, an earthling, wrote: >> >>>Hugo Kornelis wrote: >>> >>>>Within the context of databases used as backend to ERP packages, more >>>>functionality of the database is irrelevant. >>> >>>Nonsense.
>
> [snip]
>
>
>>Historically, that is NOT a nonsensical claim. >> >>SAP R/3 would be a meaningful case in point. Due to their need to >>support Adabas-D, Informix, DB2, Oracle, and some MPE/iX database, >>they historically had to use an exceedingly thin "lowest common >>denominator" of database functionality. >> >>No triggers; no foreign keys; no stored procedures; minimal use of >>'possibly-intelligent' types (e.g. - date types). >> >>They couldn't depend on having anything more because of the variations >>between products.
>
> [snip]
> Interestingly, Oracle Apps does the same thing to some degree for a large
> majority of the underlying database - no primary keys, compensated for in
> large part by unique indexes (which are a different non-logical construct
> and behave differently than PK's), and no implemented foreign key
> enforcement. However, triggers are used.
>
> I imagine Oracle's reasoning for this architecture is relatively analogous
> to the lowest common denominator reasoning you mention that SAP adopted for
> its approach. I personally haven't seen an Oracle ERP Applications
> implementation on a non-Oracle DBMS, but an examination of their current
> implementations seems to imply a desire to at least have the capability of
> accomodating multiple vendor DBMS's.
>
> One mitigating factor that might prove to be superior to that of SAP or
> other ERP products is that a logical model (versus implementation) is
> available as part of a ERTM and these logical constructs are fully
> documented in an ERP application level data dictionary, the structure of
> which is virtually identical to the underlying DBMS data dictionary.
>
> - Dan
But a very large number of referential constraints enforced by foreign keys. And to me at least ... it is hardly a good design in that respect.
-- Daniel A. Morgan University of Washington damorgan_at_x.washington.edu (replace 'x' with 'u' to respond)Received on Tue Jan 25 2005 - 16:45:56 CET