Re: Foreign key in Oracle Sql

"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