Альтернативы Entity-Attribute-Value (EAV)?

Question

Наша база данных разработана на основе модели EAV (Entity-Attribute-Value).Те, кто работал с моделями EAV, знают все дерьмо, которое идет с целью гибкости.

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

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

Ура, Мош

Answer 1

Есть разница между EAV, сделанным верно или плохо; 5NF сделано квалифицированными людьми или теми, кто не знает, что делать.

Шестая нормальная форма является неприводимой нормальной формой (дальнейшая нормализация невозможна). Он устраняет многие из распространенных проблем, таких как «Нулевая проблема», и предоставляет оптимальный метод определения пропущенных значений. Это академически и технически надежный NF. Нет никаких продуктов, чтобы поддержать это, и это обычно не используется. Для правильной и последовательной реализации требуется каталог для реализации метаданных. Конечно, SQL, необходимый для навигации, становится еще более громоздким (SQL уже является громоздким повторным объединением), но это легко преодолеть, автоматизировав производство SQL из метаданных.

EAV - это частичный набор или подмножество 6NF. Проблема в том, что обычно это делается для какой-то цели (чтобы можно было добавлять столбцы без необходимости вносить изменения в DDL), и людьми, которые не знают о 6NF и которые не реализуют метаданные. Дело в том, что 6NF и EAV, как принципы и концепции, дают существенные преимущества и повышают производительность; но обычно это не реализуется должным образом, и выгоды не реализуются. Многие реализации EAV являются бедствиями не потому, что EAV плох, а потому, что реализация плохая.

Например. Некоторые люди думают, что SQL, необходимый для построения строк 3NF из базы данных 6NF / EAV, сложен: нет, он громоздок, но не сложен. Более важно то, что может быть предоставлен обычный SQL VIEW, чтобы все пользователи и инструменты отчетов могли видеть только прямой 3NF VIEW, а проблемы 6NF / EAV были для них прозрачными. Наконец, требуемый SQL может быть автоматизирован, поэтому трудозатраты, с которыми сталкиваются многие, совершенно не нужны.

Таким образом, ответ на самом деле таков: Шестая Нормальная Форма, являющаяся отцом EAV, и более чистая форма, является заменой ей. Предостережение: убедитесь, что все сделано правильно. У меня есть один большой 6NF дБ, и он не страдает ни от каких проблем, о которых пишут люди, он прекрасно работает, клиент очень доволен (дальнейшая работа не является признаком полного функционального удовлетворения).

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

Другой вопрос EAV

Answer 2

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

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

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

Answer 3

Добавить к ответам от @NickLarsen и @PerformanceDBA

Если вам нужно отслеживать исторические изменения таких вещей, как имя поля, вы можете посмотреть что-то вроде Медленно меняющиеся размеры . Мне кажется, что вы используете EAV для моделирования динамических размерных моделей (возможно, списков поиска).

Самый простой (и, вероятно, наименее эффективный) способ достижения этого состоит в том, чтобы включить поле даты «как» в таблицах EAV, и всякий раз, когда происходит изменение, вставлять новую запись (вместо обновления существующей записи) с помощью текущая дата. Это означает, что вам нужно изменить свои запросы, чтобы они всегда включали или искали дату «по состоянию на», или по умолчанию «сейчас», если ни один из них не предоставлен. Ваша базовая сущность, которая присоединяется к объектам EAV, должна будет затем запросить «top 1» из таблицы EAV, где «по состоянию на» дата меньше или равна дате «последнего обновления» строки, упорядоченной по «по состоянию на» по убыванию. В худшем случае, если вам нужно отследить самое последнее изменение в заданной строке, в которой изменились как имя (сохраненное в таблице «атрибутов»), так и значение, вы должны связать эту логику с таблицей значений, используя «последний измененный» строки, чтобы найти соответствующее значение для этой конкретной даты.

Это, очевидно, может генерировать БОЛЬШИЕ объемы данных, если есть много изменений. Вот почему этот подход называется «медленно» меняющимся. Он предназначен для размерных значений, которые могут меняться, но не очень часто. Чтобы повысить производительность запросов, должны помочь индексы в полях «как» и «последний измененный».

Answer 4

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

Я думаю, создание вашего скрипта, который генерирует таблицы и запросы - ваш лучший шанс.