Oracle для профессионалов Том Кайт торгово-издательский дом DiaSoft

Независимость от СУБД?
Вы, наверное, уже поняли направление моей мысли. Я ссылался на другие СУБД и
описывал различия реализации одних и тех же возможностей в каждой из них. Я убеж-
ден: за исключением некоторых приложений, исключительно читающих из базы дан-
ных, создать полностью независимое от СУБД и при этом масштабируемое приложение
крайне сложно и даже практически невозможно, не зная особенностей работы всех
СУБД.
Например, давайте вернемся к первому примеру планировщика ресурсов (до добав-
ления конструкции
 FOR UPDATE).
Предположим, это приложение было разработано
на СУБД с моделью блокирования/обеспечения одновременного доступа, полностью от-
личающейся от принятой в Oracle. Я собираюсь продемонстрировать, что при переводе
приложения с одной СУБД на другую необходимо проверять, работает ли оно коррек-
тно в новой среде.
Предположим, что первоначально приложение по планированию ресурсов работало
в СУБД, использующей блокирование на уровне страниц и блокировку чтения (чтение
блокируется при изменении считываемых данных), и для таблицы
 SCHEDULES
был
создан индекс:
create index schedules_idx on schedules(resource name, start_time);
59

---

60
Глава 1
Предположим также, что бизнес-правило было реализовано с помощью триггера (пос-
ле выполнения оператора
 INSERT,
но перед фиксацией транзакции мы проверяем, что
для указанного временного интервала в базе данных имеется только наша, только что
вставленная строка). В системе с блокированием на уровне страниц, из-за изменения
страницы индекса по столбцам
 RESOURCE_NAME
и
 START_TIME,
очень вероятно,
что транзакции будут выполняться строго последовательно. Система будет выполнять
вставки поочередно, поскольку страница индекса блокируется (все близкие значения по
полю START_TIME для одного ресурса
 RESOURCE_NAME
будут находиться на той
же странице). В такой СУБД с блокированием на уровне страниц наше приложение,
вероятно, будет работать нормально, так как перекрытие выделяемых ресурсов будет
проверяться последовательно, а не одновременно.
Если просто перенести это приложение в СУБД Oracle, исходя из предположения,
что она работает точно так же, можно получить шок. В СУБД Oracle, выполняющей
блокирование на уровне строк и не блокирующей чтения, оно окажется некорректным.
Как уже было показано, необходимо использовать конструкцию FOR UPDATE для упо-
рядочения доступа. Без этой конструкции два пользователя могут зарезервировать ре-
сурс на одно и то же время. Это будет прямым следствием непонимания особенностей
работы используемой СУБД в многопользовательской среде.
С подобными проблемами я сталкивался многократно при переносе приложений из
СУБД А в СУБД Б. Когда приложение, без проблем работавшее в СУБД А, не работает
или работает весьма странно в СУБД Б, сразу же возникает мысль, что "СУБД Б — пло-
хая". Правда, однако, в том, что СУБД Б работает
 иначе.
Ни одна из СУБД не ошибает-
ся и не является "плохой" — они просто разные. Знание и понимание особенностей их
работы поможет успешно решить подобные проблемы.
Совсем недавно я помогал перевести код с языка Transact SQL (язык создания хра-
нимых процедур для СУБД SQL Server) на PL/SQL. Разработчик, занимавшийся пере-
водом, жаловался, что SQL-запросы в Oracle возвращают "неправильный" ответ. Запро-
сы выглядели следующим образом: