| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Theory v Practice
Craig,
Wow - You stirred up some emotions with this question. I'm going to play devil's advocate and say that I have seen instances where RI is not in the database layer. It's probably more common in warehousing because you have to load data even if some constraints are violated and then deal with them later.
For example, if the General Ledger says $1,000 was transferred to Cost Centre 1000 and we thought Cost Centre 1000 was closed we still need to report the $1,000. Yes, it probably indicates a problem in the General Ledger, but I've work in places where you just have to deal with it. These problems tend to only occur in large organisations with hundreds of systems and an unlucky data warehouse that's meant to join all the data back together. Also from a performance point of view I have heard that it can be faster to check say 1,000,000 rows for RI after loading, as opposed to 1 row at a time - someone with intimate knowledge or Oracle's RI implementation may shoot me down on that suggestion though.
In your example though we're talking about a single OLTP system. Have I seen an OLTP without RI - Yes. The system was an OO app with Oracle implementing the persistent objects. Let's pretend it was for a City Council, and there was a Payment object. Two of the attributes of the Payment object are called PaymentIsForObject (describes an associated object by name) and PaymentIsForKey (contains the key value of another object). This other object though could be one of many things, perhaps ParkingFine or LandTax or GarbageCollection. Therefore the RI of PaymentIsForKey depends on the value of PaymentIsForObject. Again perhaps someone can confirm if Oracle can do conditional RI like this, however at the time I was lead to believe that it couldn't (I wasn't the DBA on this project).
As others also mentioned - leaving RI out of the database still leaves a pile of functionality available - complex queries, indexing, partitioning, etc.
I do agree with the others though - Leaving RI out of the database probably introduces a lot of risk but there may be a valid reason for doing so. On the other hand, is they don't have a good reason for leaving it out then put it in. Worst case, argue that it can be put in since their application will make it redundant anyway - then as soon as the Oracle RI rejects a record you can laugh in their face!
Please don't yell at me anybody - I just felt that I had to balance the argument.
"Craig Healey"
<C.Healey_at_hhsu To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
k.com> cc:
Sent by: Subject: Theory v Practice
root_at_fatcity.c
om
24/10/2002
03:45
Please respond
to ORACLE-L
The developers working on our new VB app are also responsible for
setting up the Oracle DB behind it. The app is for an order
entry/despatch/warehouse system with >5 million customers and >1000
orders per day. We have nearly 400 tables. They are not planning on
using primary keys/secondary keys, as they say they will handle all the
constraints via VB.
I only have a theoretical knowledge of database design, which says this
is very wrong. Is the Oracle system being used as anything more than an
expensive file system? In real world scenarios, is this a common
practice?
Regards
Craig Healey
This email and any files transmitted with it are confidential and intended
solely
for the use of the individual or entity to whom they are addressed and may
contain
confidential and/or privileged material. Any review, retransmission,
dissemination
or other use of, or taking of any action in reliance upon, this information
by
persons or entities other than the intended recipient is prohibited.
Statements
and opinions expressed in this e-mail may not represent those of the
company.
If you have received this email in error please notify system.administrator_at_hhsuk.com
This footnote also confirms that this email message has been swept by
MIMEsweeper
for the presence of computer viruses (www.mimesweeper.com)
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Craig Healey INET: C.Healey_at_hhsuk.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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 Wed Oct 23 2002 - 19:13:35 CDT
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Privileged/Confidential information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply e-mail or by telephone on (61 3) 9612-6999. Please advise immediately if you or your employer does not consent to Internet e-mail for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of Transurban City Link Ltd shall be understood as neither given nor endorsed by it. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Mark Richard INET: mrichard_at_transurban.com.au Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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).
 |
 |