Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Limits on referential integrity

RE: Limits on referential integrity

From: Mercadante, Thomas F <Thomas.Mercadante_at_Labor.State.Ny.Us>
Date: Tue, 22 Jan 2002 10:48:32 -0800
Message-ID: <F001.003F778A.20020122102008@fatcity.com>

"We didn't have any problems with this application until you guys started writing reports".

gotta-love-it! it is one of the all-time best I've ever heard.

Tom Mercadante
Oracle Certified Professional

-----Original Message-----
Sent: Tuesday, January 22, 2002 11:47 AM To: Multiple recipients of list ORACLE-L

HI Dennis,

The er diagram being generated should contain the attributes associated with an entity and the business rules that affect the attributes and the relationships between entities. If they are in fact "real business rules" then we have no choice but to enforce these rules.  The only question is
where this should be done. I vote database because this is where we can ensure that it Always occurs. Anyplace else we just HOPE it occurs.

All groups that will use this databases for reporting, etc, will assume that data contains the integrity inferred by the model. This could cause reports to be generated that are just plain wrong. And whose fault would this be, I bet it would be the dba's.

I took over as project manager on a system that was designed without constraints (except pk). When I was assigned I was told that this would be a simple assignement all that remained to be done was to define and complete the needed reports. We found it impossible to report on this data because it followed NONE of the business rules. When I approached one of the original developers who was no longer working on the project about the problems we were having with the reports. He responded "We didn't have any problems with this application until you guys started writing reports". Still one of my favorite lines of all time right up there with the "if it don't blink it don't work" but that is another story. By then, Oracle7 time frame we had no choice but to clean up the data and then try to identify where in the programs this occurred and fix it at the same time. It was a nightmare I am just now (almost 10 years) able to smile about :-). I became an expert at using the exceptions table, and a huge fan of properly implemented business rules.

Bottom line, in my opinion, the only choice regarding business rules is where to enforce them. if they are not enforced in the database you don't really know if they are enforced are not.

I haven't done anything with Java myself, another lister mentioned the problems with j2ee. I wonder if having the constraints set to evaluate on commit would handle this problem.....

Hope this helps,
John

DWILLIAMS_at_LIFETOUCH.COM wrote:

>Cherie - This is an OLTP application. I haven't received the schema yet.
The
>performance goal is a good question, and I will ask it to the group when I
>find a good opportunity. Basically, they are looking for "reasonable"
>response times for on-line users.
> The development manager keeps saying that everything is still very
>preliminary, but they want to go ahead and create a schema so that they can
>start playing around with code. My cynical DBA side says that preliminary
>stuff tends to freeze in place pretty quickly.
> Basically, when you review a model, how many constraints on a table
>do you have to see to before you say "good grief, what a mess!". Or are
>there more critical points, like how many levels of table hierarchy, that
>are more important?
>Thanks for your questions, because you have given me more issues to
>consider.
>Dennis Williams
>DBA
>Lifetouch, Inc.
>dwilliams_at_lifetouch.com
>
>
>-----Original Message-----
>Sent: Tuesday, January 22, 2002 6:46 AM
>To: Multiple recipients of list ORACLE-L
>
>
>
>Dennis,
>
>How many constraints are you talking about? About how many constraints
>per table?
>What kind of app is it? OLAP? Data Warehouse?
>
>What kind of performance requirements have been set?
>
>Cherie Machler
>Oracle DBA
>Gelco Information Network
>
>
>
>
> DENNIS WILLIAMS
>
> <DWILLIAMS_at_LIFE To: Multiple recipients of
>list ORACLE-L <ORACLE-L_at_fatcity.com>
> TOUCH.COM> cc:
>
> Sent by: Subject: RE: Limits on
>referential integrity
> root_at_fatcity.co
>
> m
>
>
>
>
>
> 01/21/02 04:35
>
> PM
>
> Please respond
>
> to ORACLE-L
>
>
>
>
>
>
>
>
>
>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.
>dwilliams_at_lifetouch.com
>
>
>-----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 <DWILLIAMS_at_LIFETOUCH.COM>
>Sent by: root_at_fatcity.com
>01/21/02 01:35 PM
>Please respond to ORACLE-L
>
>
> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> 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.
>dwilliams_at_lifetouch.com
>
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>--
>Author: DENNIS WILLIAMS
> INET: DWILLIAMS_at_LIFETOUCH.COM
>
>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: ListGuru_at_fatcity.com (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: Jared.Still_at_radisys.com
>
>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: ListGuru_at_fatcity.com (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: DWILLIAMS_at_LIFETOUCH.COM
>
>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: ListGuru_at_fatcity.com (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: orantdba
  INET: orantdba_at_netscape.net

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: ListGuru_at_fatcity.com (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: Mercadante, Thomas F
  INET: Thomas.Mercadante_at_Labor.State.Ny.Us

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: ListGuru_at_fatcity.com (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).
Received on Tue Jan 22 2002 - 12:48:32 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US