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

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

CREATE TABLE persons (per id NUMBER (8) NOT NULL

,social security no CHAR(10) ,ss null reason CHAR(l)

CONSTRAINT per ccl CHECK (ss null reason IN (...;

, CONSTRAINT per cc2 CHECK ((sosial secutity no IS NULL OR ss null reason IS NULL)

AND social security no I ss null reason IS NOT NULL)

Доминирующее неопределенное значение

Одним из направлений практического применения столбцов, допускающих неопределенные значения, является использование их в качестве индикаторов исключений. Допустим, у нас есть таблица заказов с 100000 строк, но лишь 50-60 из них могут быть предметом споров. Мы хотим быстро находить такие строки, поэтому определяем столбец-индикатор IN DIS-PUTE и строим по нему индекс. Если сделать этот столбец обнуляемым и ограничить его значения значениями Y и NULL, то даИный индекс будет содержать элементы только для строк спорных заказов. Этот прием иногда называют превалированием неопределенных значений (dominant value null).

рекомендации по использованию неопределенных значений

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

Ф во всех случаях необходимо анализировать смысл неопределенных значений и выявлять возможную двусмысленность;

Ф использование неопределенных значений следует свести к минимуму, у1штывая их неординарное поведение и вероятную двусмысленность;

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

если использовать кодирование опасно, придется ввести новый столбец, единственное назначение которого - описывать, как следует интерпретировать неопределенное значение основного столбца;

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

в этой главе:

Тит и

.мет сировпиия

Выбор ключей и индексов

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

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