05.11.2015 Views

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 8 ■ TRANSACTIONS 263<br />

“statement.” If I have many SQL statements in a PL/SQL stored procedure, then each SQL<br />

statement will have its integrity constraints validated immediately after their individual execution,<br />

not after the stored procedure completes.<br />

So, why are constraints validated after the SQL statement executes? Why not during? This<br />

is because it is very natural for a single statement to make individual rows in a table momentarily<br />

“inconsistent.” Taking a look at the partial work by a statement would result in <strong>Oracle</strong><br />

rejecting the results, even if the end result would be OK. For example, suppose we have a table<br />

like this:<br />

ops$tkyte@ORA10G> create table t ( x int unique );<br />

Table created.<br />

ops$tkyte@ORA10G> insert into t values ( 1 );<br />

1 row created.<br />

ops$tkyte@ORA10G> insert into t values ( 2 );<br />

1 row created.<br />

And now we want to execute a multiple-row UPDATE:<br />

ops$tkyte@ORA10G> update t set x = x+1;<br />

2 rows updated.<br />

If <strong>Oracle</strong> checked the constraint after each row was updated, then on any given day we<br />

would st<strong>and</strong> a 50/50 chance of having the UPDATE fail. The rows in T are accessed in some order,<br />

<strong>and</strong> if <strong>Oracle</strong> updated the X=1 row first, then we would momentarily have a duplicate value for<br />

X <strong>and</strong> it would reject the UPDATE. Since <strong>Oracle</strong> waits patiently to the end of the statement, the<br />

statement succeeds because by the time it is done, there are no duplicates.<br />

DEFERRABLE Constraints <strong>and</strong> Cascading Updates<br />

Starting with <strong>Oracle</strong> 8.0, we also have the ability to defer constraint checking, which can be<br />

quite advantageous for various operations. The one that immediately jumps to mind is the<br />

requirement to cascade an UPDATE of a primary key to the child keys. Many people will claim<br />

that you should never need to do this—that primary keys are immutable (I am one of those<br />

people)—but many others persist in their desire to have a cascading UPDATE. Deferrable constraints<br />

make this possible.<br />

■Note It is considered an extremely bad practice to perform update cascades to modify a primary key. It<br />

violates the intent of the primary key. If you have to do it once to correct bad information, that is one thing,<br />

but if you find you are constantly doing it as part of your application, you will want to go back <strong>and</strong> rethink<br />

that process—you have chosen the wrong attributes to be the key!<br />

In prior releases, it was actually possible to do a CASCADE UPDATE, but doing so involved<br />

a tremendous amount of work <strong>and</strong> had certain limitations. With deferrable constraints, it<br />

becomes almost trivial. The code could look like this:

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!