Re: Oracle Takeover Bid of PeopleSoft Falls Through

karthik wrote:

> That, i would blame it on the guy who does and not on the ERP vendor.
> I can speak from experience that its actually a bigger mess to store the
> foreign keys/delete rules in the database if you have a huge ERP
> application connecting to 500-600 tables. The main problem is that these
> rules are not SQL standard. They depend heavily on the vendor. You
> dont want to end up in a situation where your ERP behaves differently
> with different databases!. If you try to enforce standardization, you
> end up with the lowest common denominator ---> and lose functionality.
>
> Storing delete rules /Foreign keys in the database is a must if you have
> only one database. If you connect to two, you can probably still
> implement it. But if your ERP connects to 5-6 different brands (like
> Oracle, SQLBASE, Informix etc.), we descend into madness if we try to do
> things at the DB level and optimize it for each database.
>
> From experience, even having stored procedures/triggers must be avoided
> as much as possible if performance is not an issue (as in several master
> data screens). Imagine having to change 4-5 stored procedure programs
> and having to test them for each database for every line of changed code.!
>
> Front end logic (like in VB, Oracle Forms and Centura) is much more
> easier to maintain. Its suboptimal as its slower. But where performance
> is not an issue, one is better of putting the logic in the front end
> if we are connecting to 3-4 databases.
>
> Daniel Morgan wrote:
>
> > karthik wrote:
> >
> >
> >><snipped>
> >>
> >>
> >>True, Oracle ERP does have foreign keys. But do you know why other ERP
> >>systems may not?. This is because almost any good ERP will implement
> >>their own data dictionary with respect to foreign keys. Meaning, they
> >>will enforce the delete rules themselves.
> >>
> >><snipped>
> >>
> > Which is 100% effective right up to the absolutely inevitable moment when
> > someone connects using any other front-end tool, SQL*Plus, MS Access, VB,
> > ColdFusion, and makes a horrific mess of it all.
> >
> > And I can't think of a single instance where this has not happened at some
> > point in time.
> > --
> > Daniel Morgan
> > http://www.outreach.washington.edu/extinfo/certprog/oad/oad_crs.asp
> > damorgan_at_x.washington.edu
> > (replace 'x' with a 'u' to reply)
> >
> >

Sorry ... but nonsense. No one asks you to store these things in the database. The data dictionary already does it.

What is required is that your implementation care more about being a relational database with data integrity than it does with being a proprietary monster that makes it harder for others to modify it without paying your consulting staff $200+ to do what otherwise would be simple stuff.

This type of database usage is driven by greed ... not technology.

--
Daniel Morgan
http://www.outreach.washington.edu/extinfo/certprog/oad/oad_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)