Тестируйте все возможные комбинации NULL-значений

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

Исключения
Если число комбинаций, нуждающихся в проверке, непомерно велико, не пытайтесь проделать их все. Подумайте лучше об изменении схемы — не слишком ли в ней много столбцов, допускающих NULL?

Тестируйте все ограничения СНЕСК()

Обоснование
Выделите все ограничения CHECK в DDL и просмотрите их. Проверьте — действительно ли одним и тем же элементам данных во всех таблицах сопоставлены одни и те же правила? Если модель корректна, к некоторым атрибутам всегда будут применимы одинаковые ограничения CHECK. Например, коды UPC будут проверяться одинаково в любом месте схемы. У других атрибутов возможны различные ограничения в различных таблицах. Например, разумно предположить, что на количество единиц товара повсеместно наложено ограничение “CHECK (quantity >= 0)”. Но вот в одном месте вам встретилось ограничение “CHECK (quantity > 0)”. Ошибка это, или нулевое значение здесь действительно исключено? Вам необходимо посмотреть и проверить.

Исключения
Нет.

Будьте внимательны к символьным столбцам

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

Исключения
Нет.

Проверяйте зависимость от размера

Обоснование
Одна из проблем с небольшими наборами тестовых данных заключается в том, что на стадии проверки они ведут себя идеально, но на практике, когда размеры таблиц станут больше, вы столкнетесь с постепенным падением производительности или даже приведете систему к катастрофе. В последнем случае падение производительности происходит внезапно, когда “последняя соломинка ломает спину верблюда”. Существует и чисто физическая подоплека катастрофы, например чрезмерная подкачка страниц с жесткого диска. Откровенно говоря, в такой ситуации вам остается только ждать и надеяться, что это было случайностью.
Постепенное падение производительности — меньшее зло. Вы можете следить за системой, наблюдать за происходящими изменениями и начать действовать, прежде чем произойдет что-нибудь страшное. Плохо то, что переход от меньшего зла к большему может произойти очень быстро. Запрос, который хорошо работал на нескольких тысячах строк тестовых данных, “выходит из себя”, когда дело доходит до нескольких миллионов строк. Постарайтесь проводить тест на наборах данных, заведомо больших, чем текущий вариант реальной БД. Это позволит вам нащупать границу, после которой возникает ошибка.

Исключения
Нет.

ГЛАВА 7.
Представления

Слепцы и слон

Джон Годфри Сакс (John Gogfrey Saxe) (1816-1887)* * Перевод Д. 3. Вибе.

Представление (view) — это виртуальная таблица, задаваемая оператором SELECT, который хранится в БД. Выражение SQL, в котором описано представление, выполняется только при обращении к нему в другом выражении. Согласно стандарту, представления должны действовать так, словно являются реальными таблицами, но на практике оптимизатор волен либо “материализовать” представление в виде физической таблицы, либо вставить в определение запроса соответствующий оператор SELECT. Существует шесть основных способов применения представлений, о которых мы поговорим в этой главе.