ггасам - по умолчанию использовать для элементов Forms $$DATE$$ или $$EDATETIME$$.

К сведению

Не смешивайте эти два метода, т.е. не применяйте $$DATETIME$$ как значение даты и времени по умолчанию с последующим обращением к SYSDATE для выполнения его проверки. У этих значений мало общего - разве что формат.

Во многих клиентских инструментальных средствах предусмотрен вызов, позволяющий получить текущее время из часов клиента (например, в Visual Basic есть функция Now).

Принимая рещение о том, откуда брать время, обязательно учтите, что делает приложение и для чего нужно время. Рекомендуем во всех случаях, когда время необходимо передавать в базу данных, использовать серверное время. Если база данных является распределенной, следует брать время с самого центрального сервера. Общее правило (имеющее к архитектуре клиент/сервер отдаленное отношение) звучит так: любая процедура, в которой используется время, должна получать его один и только один раз, чтобы передавать одно и то же время. Вряд ли вы обрадуетесь, когда, закодировав соединение по метке времени, увидите, что данное конкретное время отличается на две-три секунды из-за того, что SYSDATE использовалось в одной долгой транзакции не один, а несколько раз.

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

Проектирование для распределенных баз данных

в этой главе:

Когда иепользоеать распределенные бпяы данных?

Эволюция средств поддерлски распрсдслетш данных Oracle

Выбор стратегии распределения данных

Примерные сценарии

Исполыювапис расн редел епных бал данных для iuf>exoda в аварийный режим

Другие факторы, влияющие па проектирование

Раснредслепие дачтп. реноме

В этой главе мы продолжим наше исследование на тему о том, как совершенствовать методы проектирования с учетом использования сетей. В главе 11 мы изучили особенности проектирования баз данных Oracle для модели клиент/сервер. Логично, что теперь необходимо рассмотреть, какое влияние на проектирование оказывает распределение функций хранения данных и управления ими между несколькими серверами.

Когда использовать распределенные базы данных?

Существует много причин, которые могут подтолкнуть вас к мысли об использовании распределенной базы данных. Наиболее важными из них, на наш взгляд, являются следующие:

Необходимость разместить часто используемые данные близко к клиентским приложениям, которым нужно к ним обращаться, и таким образом свести к минимуму число сообщений в сети и время доступа.

Желание расположить изменчивые данные в одном месте, сведя таким образом к минимуму проблемы, связанные с наличием нескольких обновляемых копий таких данных.

Стремление уменьшить влияние единичного отказа, например отключения сервера.

Если эти факторы являются ключом к успешной работе ваших приложений, то распределенная база данных может быть именно тем, что нужно. Однако следует учитывать, что и проектирование распределенной базы данных, и ее сопровождение после ввода в эксплуатацию нельзя назвать тривиальными задачами.

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

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

Однако в главе И мы не исследовали все последствия от применения такой модели. В примере, приведенном на рис. 12.1, показаны два связанных центральных сервера, каждый из которых непосредственно соединен с рядом промежуточных серверов. Давайте предположим, что связь, показанная между этими двумя серверами, необходима. Это означает, что центральные данные нельзя разделить таким образом, чтобы все записи, интересующие клиентов А и В, можно было держать на сервере X, а данные, интересующие клиентов С, - на сервере Y.

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

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

Производительность: и общая пропускная способность, и время реакции приложения на каждом клиенте должны соответствовать поставленным требованиям.

Работоспособность: приложение должно быть достаточно надежным.