Oracle для профессионалов
Выглядит он весьма просто, но
Выглядит он весьма просто, но выполнять подобную транзакцию в каждый момент времени может только один пользователь. Необходимо изменить соответствующую строку, чтобы увеличить значение счетчика, а это приведет к поочередному выполнению операций. Не более одного сеанса в каждый момент времени будет генерировать новое значение ключа. Проблема осложняется тем, что реальные транзакции намного больше транзакции, показанной выше. Показанные в примере операторы UPDATE и SELECT — лишь два из множества операторов, входящих в транзакцию. Необходимо еще вставить в таблицу строку с только что сгенерированным ключом и выполнить необходимые действия для завершения транзакции. Это упорядочение доступа будет огромным ограничивающим фактором для масштабирования. Подумайте о последствиях, если этот метод применить для генерации номеров заказов в приложении для обработки заказов на Web-сайте. Одновременная работа нескольких пользователей станет невозможной, — заказы будут обрабатываться последовательно.
Правильное решение этой проблемы состоит в использовании для каждой СУБД соответствующего кода. В Oracle (предполагается, что уникальный ключ необходимо генерировать для таблицы T) лучшим способом будет:
create table t ( pk number primary key, ... ); create sequence t_seq; create trigger t_trigger before insert on t for each row begin select t_seq.nextval into :new.pk from dual; end;
В результате каждая вставляемая строка автоматически и незаметно для приложения получит уникальный ключ. Тот же эффект можно получить и в других СУБД с помощью их типов данных — синтаксис оператора создания таблицы изменится, а результат будет тем же. Мы использовали второй вариант — специфические средства каждой СУБД для неблокируемой, высокопараллельной генерации уникального ключа, что, однако, не потребовало реальных изменений в коде приложения — все необходимые действия выполнены операторами DDL.
Приведу еще один пример безопасного программирования, обеспечивающего переносимость. Если понятно, что каждая СУБД реализует одни и те же возможности по-разному, можно при необходимости создать дополнительный уровень доступа к базе данных. Предположим, вы программируете с использованием интерфейса JDBC. Если используются только простые операторы SQL, SELECT, INSERT, UPDATE и DELETE, дополнительный уровень абстракции скорее всего не нужен. Можно включать код SQL непосредственно в приложение, если использовать конструкции, поддерживаемые во всех СУБД, с которыми должно работать приложение. Другой подход, одновременно упрощающий перенос и повышающий производительность, состоит в использовании хранимых процедур, возвращающих результирующие множества. Если разобраться, окажется, что все СУБД могут возвращать результирующие множества из хранимых процедур, но способы при этом используются абсолютно разные. Для каждой СУБД придется написать свой исходный код.
Forekc.ru
Рефераты, дипломы, курсовые, выпускные и квалификационные работы, диссертации, учебники, учебные пособия, лекции, методические пособия и рекомендации, программы и курсы обучения, публикации из профильных изданий