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 - 09:45:56 CST
