Альтернативы атрибуту-атрибуту (EAV)?

Question

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

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

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

Приветствия, Мош

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

Other EAV Question

Answer 4

Чтобы добавить ответы из @NickLarsen и @PerformanceDBA

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

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

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