Для первой части дискуссии предположим, что ограничения находятся в режиме IMMEDIATE, что является нормой. В этом случае ограничения целостности проверяются немедленно после обработки всего оператора SQL. Обратите внимание, что я использую термин “оператор SQL”, а не просто “оператор”. Если у меня есть много операторов SQL в хранимой процедуре PL/SQL, то за исполнением каждого из них будет немедленно следовать верификация ограничений целостности, а не после того, как завершится вся процедура.
Так почему же ограничения проверяются после выполнения оператора SQL? Почему не во время? Дело в том, что для отдельных операторов очень естественно делать отдельные строки таблицы на мгновение “несогласованными”. Обращение к результату частичной работы оператора может заставить Oracle отклонить такой результат, даже если общий результат всей работы будет корректным. Например, предположим, что у нас есть следующая таблица:
ops$tkyte@ORA10G> create table t ( x int unique );
Table created.
Таблица создана.
ops$tkyte@ORA10G> insert into t values ( 1 );
1 row created.
1 строка создана.
ops$tkyte@ORA10G> insert into t values ( 2 );
1 row created.
1 строка создана.
И мы хотим выполнить многострочный UPDATE:
ops$tkyte@ORA10G> update t set x = x+1;
2 rows updated.
2 строки создано.
Если Oracle проверит ограничение после обновления каждой строки, то в любой день существует вероятность 50/50 того, что UPDATE провалится. Строки в T доступны в некотором порядке, и если Oracle обновит строку X=1 первой, то если получается мгновенное дублированное значение X, оператор UPDATE будет отвергнут. Но поскольку Oracle терпеливо ожидает конца работы оператора, он завершается успешно, поскольку на момент его завершения дубликатов уже нет.
< Предыдущая | Следующая > |
---|