Не применяйте в реляционной БД объектно-ориентированный дизайн

Обоснование
Много лет назад в городе Рапид-Сити (Южная Дакота) состоялось совещание комитета по стандартам БД INCITS H2 (известного так же, как комитет ANSI ХЗН2). Двумя достопримечательностями совещания были гора Рашмор и Бьерн Страуструп (Bjarne Stroustrup). Г-н Страуструп сделал доклад про то, как в Bell Labs специально для нас разрабатывают язык C++ и объектно-ориентированное программирование, а потом мы перешли к вопросам.
Один из вопросов заключался в том, как мы должны использовать объектно-ориентированное программирование в SQL Он ответил, что фирма Bell Labs испытала четыре различных подхода к этой проблеме и — при всех ее талантах — пришла к выводу, что делать этого не следует. Объектно-ориентированный подход хорош для программирования, но смертелен для данных.

Таблица не является экземпляром объекта

В правильно разработанной схеме таблицы не появляются и не исчезают, подобно экземплярам объекта. Таблица представляет собой набор сущностей, или отношение. Возможность их появления (CREATE TABLE) и исчезновения (DROP TABLE) словно перемещает нас в волшебный мир, в котором новые сущности создаются мановением руки любого пользователя. Точно так же нет в SQL и идентификаторов объекта. Идентификаторы GUID, автонумерация и все остальные нестандартные указатели в длительной перспективе оказываются бесполезными. Я много раз наблюдал за попытками втиснуть модели ООП в SQL, и все они разваливались максимум через год. Каждая опечатка становится новым атрибутом, запросы, выполнить которые было бы просто в реляционной модели, превращаются в многотабличные монстроподобные внешние объединения, избыточность нарастает по экспоненте, разработать ограничения практически невозможно, поэтому можно распрощаться с целостностью данных, и т.д.
При обсуждении преимуществ ООП и реляционной модели в группе новостей comp.databases.theory, которое состоялось в октябре 2004 г., один опытный программист написал так:
Хочу вам сказать то, что вы и так знаете, — вы на 100% правы. Я увяз в попытках приспособить объектно-ориентированную схему к реляционной БД. Трудно даже представить себе, сколько гимнастики потребовалось мне для выполнения простейшего запроса. Потребовалось шесть человеко-часов (я и еще один программист потратили три часа), чтобы получить в итоге запрос, эквивалентный следующему:

SELECT * FROM Field_Offices;

Нужные данные содержали название офиса, адрес, имя менеджера и телефон. Окончательная версия запроса занимала почти целую страницу, требовала объединения различных таблиц для каждого элемента данных (каждый элемент данных представляет собой объект, а у каждого объекта — собственные атрибуты, и потому для него требуется собственная таблица). Добавьте к этому чудовищные таблицы со связями, необходимые для получения правильного экземпляра каждого объекта.
Кстати, который экземпляр правильный? Конечно же, самый последний, если только он не помечен, как неиспользуемый. Если он помечен нужно искать экземпляр, который помечен, как используемый. К сожалению, у метки не всегда одно и то же значение. Эти таблицы со связями — самые большие в БД. Всего лишь за год они выросли до миллионов строк, необходимых для отслеживания менее чем 80000 экземпляров объектов.

Не используйте в реляционных БД дизайн “сущность-атрибут-значение”

Дизайн “сущность-атрибут-значение” (Entity-Attribute-Value, EAV) особенно популярен среди “чайников”, принадлежащих к экстремальной школе разработки ПО. Ее девиз “Сначала программируй, потом думай”.
Методика эта вкратце состоит в создании одной огромной таблицы с тремя столбцами метаданных: название сущности, название атрибута, значение атрибута. Это позволяет пользователям в процессе работы с БД создавать новые сущности. Если один из них хочет внести в БД сущность “батон”, а другой — “булка”, они оба имеют возможность это сделать.
Значения должны храниться с использованием наиболее общего типа данных, поэтому в модели EAV широко используются столбцы VARCHAR(n). Попробуйте наложить на такой столбец какое-либо ограничение.

Исключения
Нет. Имеются лучшие инструменты для сбора данных в свободном формате.

ГЛАВА 4.
Шкалы и измерения

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

Теория измерений

Измеряйте все измеримое и старайтесь делать
измеримым то, что пока таковым не является.
Галилей (1564-1642)

Теорией измерений называется раздел прикладной математики, связанный с анализом данных. Результат измерения — не то же самое, что измеряемый атрибут, а само измерение — не просто процесс назначения числа предмету или его атрибуту. Измерение — это выделение структурного свойства сущности, которое может быть выражено числом или другим вычисляемым символом. Основу измерения составляет шкала, а упомянутые числа или символы представляют собой единицы измерения.
Как ни странно, основы теории измерений лежат в области психологии, а не математики или информатики. В частности, оригинальные идеи об уровнях измерений и о классификации шкал принадлежат американскому психологу С.С.Стивенсу (S.S.Stevens). Шкалы разделяются на несколько классов в зависимости от свойств, которыми обладают или не обладают. Нас будут особо интересовать следующие свойства шкал.
1. Наличие начальной точки, или точки отсчета. Ее иногда называют нулем шкалы, но это необязательно должно быть число 0. Например, в измерении расстояний между объектами естественным началом отсчета является 0 метров — меньших расстояний не бывает. У температурной шкалы начальная точка определяется абсолютным нулем — ничто не может быть холоднее 0 градусов Кельвина. А вот у времени естественного начала отсчета нет: оно идет из бесконечного прошлого в бесконечное будущее.
2. С единицами измерения можно выполнять определенные операции. Массы можно складывать и вычитать, получая в результате также массу/ Складывать имена или размеры обуви нельзя, но их можно сравнивать.
3. У единиц имеется естественный порядок. Можно говорить о том, что данное событие произошло до или после другого события. Один предмет может быть тяжелее, длиннее или горячее другого. Алфавитный порядок является скорее произвольным, чем естественным — если те же предметы перечислить на другом языке, алфавитный порядок будет иным.
4. Для любой пары величин существует естественная метрика. Метрика не имеет отношения к Метрической системе (СИ). Это функция, которая подчиняется следующим трем правилам.
a. Метрика между объектом и им самим равна нулю шкалы. В математической нотации это свойство записывается так: М(а, а) = 0.
b. От перемены мест объектов метрика не меняется. В математической нотации М(а, b) = M(b, а).
c. Существует такая операция сложения, что М(а, b) + М(b, с) > М(а, с). Это неравенство известно как неравенство треугольника.
Несмотря на простой арифметический вид эти выражения имеют более общий смысл. Нуль в первом свойстве представляет собой точку отсчета шкалы и необязательно является числом 0. В математической записи третьего правила фигурируют арифметические знаки “плюс” и “больше или равно”, но на самом деле они символизируют более общие отношения упорядочения. Знак “больше или равно” относится к естественному порядку измеряемых атрибутов. Знаком “плюс” отмечена некая осмысленная операция в отношении этого порядка, а не только арифметическое сложение.
Наличие операций сложения и сравнения особенно полезно, поскольку означает, что измерения можно проводить в числах и что с этими числами можно выполнять простые преобразования. Например, восприятие человеком звука и света примерно пропорционально кубическому корню интенсивности, то есть, если удвоить интенсивность света или звука, то восприятие увеличится всего на 20%. Более формально это звучит так: воспринимаемая интенсивность равна физической интенсивности в степени 0,3. Зная об этом, дизайнеры звуковой техники используют регуляторы громкости, шкалы которых размечены равноотстоящими штрихами, хотя на самом деле они работают в логарифмической шкале.
Метрика шкалы необязательно обладает всеми тремя метрическими свойствами. Рассмотрим в качестве примера способ измерения расстояний не в единицах длины, а в единицах работы — старая китайская система, в которой использовались разные единицы расстояния для движения в гору и под гору. Обладает ли эта система свойством M(a, a) = 0? Да. При перемещении туда, где вы уже находитесь, работа не совершается. Обладает ли она свойством М(а, b) = М(b_} а)? Нет. Под гору идти легче, чем в гору. Подчиняется ли она неравенству M(a, b) +M(b, с) >М(а, с)? Да. Работа, совершаемая при прямом перемещении из пункта А в пункт Б, всегда будет меньше либо равна работе, совершаемой с промежуточными остановками и отклонениями от прямого пути.