Благодаря Oracle? у нас есть возможность определять процедуры, ограничения и триггеры в базе данных, поэтому их достаточно создать всего один раз и затем ввести в действие глобально. Однако даже сейгас существуют веские аргументы в пользу того, чтобы осуществлять проверку данных nej только на сервере базы данных, но и в пользовательском приложении.

Клиенстские приложения могут либо проверять данные по мере ввода] либо откладывать проверку до тех пор, пока оператор не рещит выполнить фиксацию изменений. Выбор метода в значительной степени зависит от характера приложения и компетентности конечных пользователей. В больщинстве приложений используется сочетание двух этих методов, при котором отдельные поля проверяются при вводе, а перекрестная проверка полей и записей откладывается до получения сигнала о фиксации.

Конечно, для пользователя неприятно, что он потратил время на ввод в экранную форму массы деталей лищь затем, чтобы при фиксации узнать, что первое введенное им поле неверно. Если исправить ощибку нельзя, то пользователю придется переделывать всю работу. Все это, конечно, не прибавляет пользователю оптимизма, а системе - популярности. С другой стороны, если данные проверяются в экранной форме по мере ввода, то проектировщику приходится выбирать между дублированием проверки на клиенте и частыми обращениями к серверу, увеличивающими сетевой трафик. На нащ взгляд, дополнительный трафик лучще, чем дублирование кода, и мы отдаем предпочтение проверке на стороне сервера, где это возможно. Использование промежуточных серверов (описанных ранее) может помочь уменьшить влияние этого подхода на трафик сообщений.

Недостаток немедленной проверки данных заключается в том, что правильные данные (а мы надеемся, что их подавляющее больщинство) могут проверяться дважды. Вторая проверка выполняется, когда строка зафиксирована и срабатывает триггер проверки на таблице. Как мы уже подчеркивали ранее, мы не хотим снимать этот триггер, так как он - главный страж целостности нащей базы данных. В частности, он защищает базу данных от пользователей, имеющих доступ к средствам создания нерегламентированных запросов. Это показано на рис. 11.?, где лимит кредита не может превысить указанную сумму.

Функция checkjcredit вызывается дважды - сначала явно из экранной формы для обеспечения немедленной обратной связи в процессе ввода данных, а затем неявно триггером, когда в таблице выполняется вставка или обновление.

Иногда реализацию проверки на стороне клиента оправдывают еще и такой причиной: дескать это позволяет дать пользователю более информативные сообщения об ошибках, чем те, которые поступают с сервера- при нарушении ограничения или отказе триггера. Нам кажется, что это не очень серьезный аргумент. Клиентское ПО может и должно перехватывать и преобразовывать сообщения, а не содержать и выполнять логику проверки.

Клиент

Сервер

Лимит

кредита

$1966,00

Явный вызов check cmdit при вводе данных

Изменения зафиксированы

FUNCTION check credit(creditjimit IN NUMBER) RETURN BOOLEAN IS

CREATE TRIGGER iu customer ON INSERT OF customers FOR EACH ROW IS

check credit(:new.cre<iitjlmit)

Puc. 11.7. Пример дублирования проверки на клиенте и сервере

Важно, чтобы у вас был набор стандартов на разработку ГПИ, четко определяющих подход к проверке в масштабах всего приложения. Экранные формы, которые разработаны в Oracle Forms версии 3 или более старой, а затем конвертированы с помощью какого-либо инструмента, все равно склонны вести себя, как программа, написанная в Oracle Forms версии 3, хотя и выглядят, как ГПИ. В них продолжает выполняться обширная проверка навигационных событий. Такие конвертированные экранные формы, как правило, плохо сочетаются с формами, которые с нуля разработаны в Oracle Forms версии 4.5, и весьма вероятно, что их придется переписывать. Привлекательно выглядит еще одна идея (особенно для отделов маркетинга фирм-поставщиков приложений): иметь один и тот же исходный код как для текстовых, так и для ГПИ-версий одного приложения. Но мы считаем эту идею несбыточной - из-за компромиссов, которые она предполагает.

К сведению

Помните, что, пока целостность данных обеспечивается с помощью триггеров, при проверке на стороне клиента не обязательно применять блокировки. Если ваше приложение не устанавливает блокировки до самого последнего момента, то менее вероятно, что пользователи столкнуться с конфликтами блокировки, хотя иногда они и будут получать сообщения периода фиксации о том, что транзакцию невозможно завершить, так как что-то изменилось. Эта тема рассматривается в главе 18.

Который час?

Время - это еще одна проблема в приложениях клиент/сервер. От большинства проектировщиков требуют (по крайней мере, они так думают), чтобы на клиенте можно было работать с текущими датой и временем. Во всех средах, за исключением распределенных вычислительных сред, у каждого клиента и каждого сервера есть свои системные часы, и эти часы выдают широкий диапазон несогласованных значений времени. Какое из них должно использовать приложение? Неразбериха возникает и потому, что один и тот же момент времени в разных часовых поясах представлен разным значением.

Примечание

Распределенная вычислительная среда (Distributed Computing Environment, DCE) - это стандарт, который определяет, как может взаимодействовать ячейка связанных сетью машин. Ячейку в данном контексте можно упрощенно представить как группу машин с обш,им назначением Одно из требований DCE состоит в том, что ячейка должна содержать минимум три сервера времени и иметь алгоритм, позволяющий запрашивать время способом, который гарантированно дает непротиворечивое значение в пределах всей ячейки.

Oracle поддерживает использование DCE, и эту СУБД можно конфигурировать на получение SYSDATE с помощью сервисов времени DCE. Конечно, использование DCE влечет за собой дополнительные затраты на обеспечение необходимого уровня производительности.

Если вы просто хотите снабдить меткой даты или времени новую или обновленную строку, то можно отправить на сервер SQL-предложение с псевдостолбцом, содержащим SYSDATE для определения даты. SYSDATE будет вычислена, и для строки будет применена дата и время сервера. Этот метод хорошо работает для установки меток времени и приемлем для подавляющего большинства приложений. Вот пример SQL-предложения такого типа:

UPDATE orders or

SET ord.tot amount = ord.tot amount * 1.01 , ord.latest update dt = SYSDATE WHERE ord.cus id = 1024;

Однако предположим, что от приложения требуется, чтобы пользователь видел метку времени на записи перед тем, как решать, фиксировать запись или нет. Теперь появляется выбор - приложение может запросить дату и время с сервера или воспользоваться локальными часами клиента. Причем результат в данном случае будет зависеть от того, какое средство применялось при его создании. Многие пользователи удивляются, обнаружив, что, когда локальная процедура на PL/SQL, работающая в приложении, созданном в Oracle Forms, обращается к SYSDATE, это приводит к вызову сервера для выборки текущего значения. Единственный путь обратиться к локальным