"Daniel Morgan" <damorgan@exxesolutions.com> wrote in message
news:3EEB57EA.4177408A@exxesolutions.com...
> Go for it Larry. And after you've bought it ... if they can't understand
the concept of a foreign key ...
> close 'em down.

Hmm... Do oracle apps folks understand what referential constraint (aka
foreign key) is?

Mikito Harakiri wrote:

> "Daniel Morgan" <damorgan@exxesolutions.com> wrote in message
> news:3EEB57EA.4177408A@exxesolutions.com...
> > Go for it Larry. And after you've bought it ... if they can't understand
> the concept of a foreign key ...
> > close 'em down.
>
> Hmm... Do oracle apps folks understand what referential constraint (aka
> foreign key) is?

Last time I checked the gl_interface table, alone, had 17 referential
constraints.

The equivalent table in the competing products ... zero.
--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

select * from dba_constraints
where owner in ('APPS', 'HZ', 'APPLSYS') and constraint_type = 'R'

returned just 2 foreign keys in 11.5.8. I also don't see anything but "not
null" constraints on gl_interface table. I beleive they have a metalink note
with motivation why constraints are considered "bad".

"Daniel Morgan" <damorgan@exxesolutions.com> wrote in message
news:3EFC8DEA.D292B644@exxesolutions.com...
> Mikito Harakiri wrote:
>
> > "Daniel Morgan" <damorgan@exxesolutions.com> wrote in message
> > news:3EEB57EA.4177408A@exxesolutions.com...
> > > Go for it Larry. And after you've bought it ... if they can't
understand
> > the concept of a foreign key ...
> > > close 'em down.
> >
> > Hmm... Do oracle apps folks understand what referential constraint (aka
> > foreign key) is?
>
> Last time I checked the gl_interface table, alone, had 17 referential
> constraints.
>
> The equivalent table in the competing products ... zero.
> --
> Daniel Morgan
> http://www.outreach.washington.edu/e...ad/oad_crs.asp
> damorgan@x.washington.edu
> (replace 'x' with a 'u' to reply)
>
>

On Fri, 27 Jun 2003 13:15:40 -0700, "Mikito Harakiri"
<mikharakiri@ywho.com> wrote:

>select * from dba_constraints
>where owner in ('APPS', 'HZ', 'APPLSYS') and constraint_type = 'R'
>
>returned just 2 foreign keys in 11.5.8. I also don't see anything but "not
>null" constraints on gl_interface table. I beleive they have a metalink note
>with motivation why constraints are considered "bad".


That's also my impression. And of course, people using Oracle Apps are
still forced to run Oracle 8.1.6 server *and* Oracle 8.0.6 client.
Oracle Apps, from the technical view, is just a big mess, and the
worst product they ever sold.


Sybrand Bakker, Senior Oracle DBA

To reply remove -verwijderdit from my e-mail address

"Sybrand Bakker" <gooiditweg@sybrandb.demon.nl> wrote in message
news:kr9pfv8kb2pecgmgtjvrd7gafcukljh3jt@4ax.com...
> On Fri, 27 Jun 2003 13:15:40 -0700, "Mikito Harakiri"
> <mikharakiri@ywho.com> wrote:
>
> >select * from dba_constraints
> >where owner in ('APPS', 'HZ', 'APPLSYS') and constraint_type = 'R'
> >
> >returned just 2 foreign keys in 11.5.8. I also don't see anything but
"not
> >null" constraints on gl_interface table. I beleive they have a metalink
note
> >with motivation why constraints are considered "bad".
>
>
> That's also my impression. And of course, people using Oracle Apps are
> still forced to run Oracle 8.1.6 server *and* Oracle 8.0.6 client.
> Oracle Apps, from the technical view, is just a big mess, and the
> worst product they ever sold.

Check out 9iAS - a recipe for consultancy and eternal upgrades if ever I saw
one.


--
Niall Litchfield
Oracle DBA
Audit Commission UK
*****************************************
Please include version and platform
and SQL where applicable
It makes life easier and increases the
likelihood of a good answer
******************************************

<<The equivalent table in the competing products ... zero.>>

Do you mean competing products dont understand foreign keys?

An absolute No.

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. This is because error handling
is much easier as it works across database platforms. In Oracles case,
Oracle ERP does not work with other databases. So they can enforce
delete/foreign key rules using the oracle database

I worked in a medium sized ERP firm and later was with sometime with
Oracle. In the first firm, the foreign key rules were built with the
installation - meaning the ERP has its own data dictionary. They were
pretty impressive. They worked irrespective of the database platform.
Looking back, i cant say it worked better or worse than Oracles.

But i do have heard horror stories of SAP systems creating unnecessary
indexes bordering on the ridiculous. something like:

create index my index1 on mytable (column1)
create index my index2 on mytable (column1,column2)
create index my index3 on mytable (column1,column2,column3)

This is ridiculous.

Regards
karthik


Daniel Morgan wrote:

> Mikito Harakiri wrote:
>
>
>>"Daniel Morgan" <damorgan@exxesolutions.com> wrote in message
>>news:3EEB57EA.4177408A@exxesolutions.com...
>>
>>>Go for it Larry. And after you've bought it ... if they can't understand
>>
>>the concept of a foreign key ...
>>
>>>close 'em down.
>>
>>Hmm... Do oracle apps folks understand what referential constraint (aka
>>foreign key) is?
>
>
> Last time I checked the gl_interface table, alone, had 17 referential
> constraints.
>
> The equivalent table in the competing products ... zero.
> --
> Daniel Morgan
> http://www.outreach.washington.edu/e...ad/oad_crs.asp
> damorgan@x.washington.edu
> (replace 'x' with a 'u' to reply)
>
>

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/e...ad/oad_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

On Sat, 28 Jun 2003 22:52:29 -0500, karthik <anon@anon.com> wrote:

>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.

I disagree it is easier to maintain. Usually it is spread all over the
application. Usually the unlucky third-party DBA doesn't have access
to the source/ Usually performance *is* an issue, and the application
guys are blaming the third-party DBA for it all the time.
Usually NO ONE is EVER connecting to 3-4 databases, and NO ONE is so
STUPID to use databases from different vendors.
Usually those ERP applications are just a BIG PAIN IN THE ASS


Sybrand Bakker, Senior Oracle DBA

To reply remove -verwijderdit from my e-mail address

"Mikito Harakiri" <mikharakiri@ywho.com> wrote in message
news:Qe7La.22$2b5.84@news.oracle.com...
> "Niall Litchfield" <niall.litchfield@dial.pipex.com> wrote in message
> news:3efcab88$0$961$cc9e4d1f@news.dial.pipex.com.. .
> > Check out 9iAS - a recipe for consultancy and eternal upgrades if ever I
> saw
> > one.
>
> Seems that we have "who sucks the most" competition.
>
> It is really about product definition. Find goofy RDBMS around, there is
> simply none. That's right, RDBMS is SQL execution engine with well defined
> specs.
>
> One more relatively decent oracle product: JDeveloper. Similar to RDBMS,
IDE
> is a product with well defined spec. And yet again, you'll hardly find
other
> IDE that totally sucks on the market.
>
> What is Application Server, may I ask? A random collection of goofy
> inventions like cartridges, web cache, message exchange "framework", and
> other nonsence patched to Apache?
>
> Would be interested to know what other oracle product is not a disaster.
>
>

Rhetorical question: how about the RDBMS itself. And Designer/Developer.
They *work*
If you don't want to work with Oracle products isn't it time to commit
harikiri, at least in this group?


--
Sybrand Bakker
Senior Oracle DBA

to reply remove '-verwijderdit' from my e-mail address

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/e...ad/oad_crs.asp
> > damorgan@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/e...ad/oad_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)