| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.misc -> Re: Oracle Takeover Bid of PeopleSoft Falls Through
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> >>
 |
 |