Jared - Ooh . . ooh . . that last point really grabbed my interest! The part
about "kept the RI overhead low was that all transactions tables had
surrogate keys generated from a sequence". Can you (or anyone else on the
list) give me a reference that discusses this so I can go show it to the
developers? Much appreciate.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
-----Original Message-----
Sent: Monday, January 21, 2002 6:30 PM
To: Multiple recipients of list ORACLE-L
Yeah, I've heard the performance arguments before.
I've never worked on a really large OLTP system, but I have
worked on some of 20 gig or so with a few key tables having
millions of rows ( 20 gig used to be big! ).
One in particular had quite a bit of RI. Running on a DG/UX
system with 512M Ram and 4 cpus, with 3 mirrored pairs and
2 RAID 5 stripes, we were generally happy with the performance.
The transactions were very query intensive and performed upto
about 20k transactions per day with an average transaction time
of 1-2 seconds. These were very complex transactions.
There were also 10-20 operators at any one time entering manual
transactions and doing customer service from the same database.
There was a CFO requesting all kinds of complex reports during the
middle of the day. Did I forget to mention that Oracle apps 9 was
on the same box?
RI was never to blame for performance problems.
In fact, our biggest performance problem was non-performance when
the database died. ( Steve, I couldn't resist :)
This was on Oracle 7.0.16 to start with. RI was not the cause of any
performance problems that I can recall.
One thing that kept the RI overhead low was that all transactions
tables had surrogate keys generated from a sequence.
Jared
DENNIS WILLIAMS <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/21/02 02:35 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject: RE: Limits on referential integrity
Jared - I wasn't clear, but then again it is Monday. I have a team of
inexperienced developers starting a big, new Java application. They have a
good, experienced data model consultant helping them create the data
model.
They are eager to include referential integrity. So eager it has me a
little
worried. My question: "Is there too much of a good thing?". In Oracle 7,
sometimes sites would remove RI to ensure good performance (we are
starting
this project on Oracle9i). Has anyone encountered problems with too many
constraints? Any guidelines you use with developers? Thanks.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
-----Original Message-----
Sent: Monday, January 21, 2002 4:16 PM
To: Multiple recipients of list ORACLE-L
I would be you lunch that what they are implementing in their
code is not actually RI. They may be implementing code to
ensure things get inserted in the right order, and that child rows
have a parent.
This is a very weak form of RI. Oracle is very good at implementing
RI, and it is not dependent on an application. RI in the database
is the route to choose unless there is some good reason not to.
RI in the database will prevent orphaned data created through
updates, deletes or even ( gasp! ) bugs in the app.
Programmers tend to dislike RI in the database because it
forces them to maintain data integrity in a transaction. This is
not a bad thing, it just forces them to have a good understanding
of their transactions.
Point out to them that it is less code to write as well. :)
Jared
DENNIS WILLIAMS <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/21/02 01:35 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L
<[EMAIL PROTECTED]>
cc:
Subject: Limits on referential integrity
How much referential integrity should be implemented in Oracle? We are
starting a large new Java project. Our current applications keep their
referential integrity inside their own dictionary, so I haven't had to
deal
much with referential integrity recently. Can there be too much of a good
thing? What guidelines do you tend to use? At this point the developers
are
designing the data model so they are busily linking all the little boxes.
My
attitude at this point is "implement what you've got and if there are
performance problems we'll deal with them when they arise". Can anyone
give
me a better motto?
Thanks.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: DENNIS WILLIAMS
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: DENNIS WILLIAMS
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: DENNIS WILLIAMS
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
