Как преодолеть недостатки в отчетности из базы данных EAV?

Question

Основные недостатки в проектах баз данных Entity-Attribute-Value в SQL, по-видимому, связаны с возможностью эффективного и быстрого запроса и составления отчетов по данным. Большая часть информации, которую я читаю по этому вопросу, предостерегает от внедрения EAV из-за этих проблем и общности запросов / отчетов почти для всех приложений.

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

Учитывая, что типичная нормализованная база данных (OLTP) по-прежнему не всегда является оптимальным вариантом для запуска отчетов, рекомендуется использовать базу данных «отчетности» (OLAP), в которую данные из нормализованной базы данных копируются, индексируются экстенсивно и, возможно, денормализовано для облегчения запросов. Может ли та же идея быть использована для обхода недостатков дизайна EAV?

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

Устранены ли проблемы с системами EAV, если у вас есть отдельная база данных отчетов для запросов?

РЕДАКТИРОВАТЬ: Спасибо за комментарии до сих пор. Одна из важных вещей в системе, над которой я работаю, это то, что я на самом деле говорю только об использовании EAV для одного из объектов, а не всего в системе.

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

Вот схемы таблиц и примеры данных, на которые я смотрю (очевидно, они изменились по сравнению с тем, над чем я работаю, но я думаю, что это хорошо иллюстрирует данный момент):

Таблицы EAV

Person
-------------------
-  Id - Name      -
-------------------
- 123 - Joe Smith -
-------------------

Person_Value
-------------------------------------------------------------------
- PersonId - Source - Field       - Value         - EffectiveDate -
-------------------------------------------------------------------
-      123 -    CIA - HomeAddress - 123 Cherry Ln -    2010-03-26 -
-      123 -    DMV - HomeAddress - 561 Stoney Rd -    2010-02-15 -
-      123 -    FBI - HomeAddress - 676 Lancas Dr -    2010-03-01 -
-------------------------------------------------------------------

Таблица отчетности

Person_Denormalized
----------------------------------------------------------------------------------------
-  Id - Name      - HomeAddress   - HomeAddress_Confidence - HomeAddress_EffectiveDate - 
----------------------------------------------------------------------------------------
- 123 - Joe Smith - 123 Cherry Ln -                  0.713 -                2010-03-26 -
----------------------------------------------------------------------------------------

Нормализованный дизайн

Person
-------------------
-  Id - Name      -
-------------------
- 123 - Joe Smith -
-------------------

Person_HomeAddress
------------------------------------------------------
- PersonId - Source - Value         - Effective Date - 
------------------------------------------------------
-      123 -    CIA - 123 Cherry Ln -     2010-03-26 -
-      123 -    DMV - 561 Stoney Rd -     2010-02-15 -
-      123 -    FBI - 676 Lancas Dr -     2010-03-01 -
------------------------------------------------------

Поле «Доверие» здесь генерируется с использованием логики, которую нельзя выразить легко (если вообще) с помощью SQL, поэтому моей самой распространенной операцией, помимо вставки новых значений, будет получение ВСЕХ данных о человеке для всех полей, чтобы я мог сгенерировать запись для таблицы отчетности. На самом деле это проще в модели EAV, так как я могу сделать один запрос. В нормализованном дизайне мне приходится выполнять по одному запросу на поле, чтобы избежать объединения массивного декартового произведения.

Answer 1

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

Поскольку вы четко объясняете природу проблемы «нахождением в этой схеме», мне действительно кажется, что проблема с EAV действительно из-за EAV как такового.

На самом деле, подумайте об этом: «система, которая позволяет пользователям хранить любые данные» - это эквивалент системы, которая позволяет пользователям просто определять свои relvars. Но какая часть этой системы позволяет пользователям определять ограничения для каждого атрибута? Упс, толпа EAV, кажется, пропустила не столь незначительный аспект управления данными, кажется ...

Answer 2

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

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

Удачи с этим.

Answer 3

Краткий ответ - да, база данных отчетов - это разумный подход к решению проблем отчетности из модели данных EAV.

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

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

Answer 4

С EAV проблем нет. Я трачу довольно много времени на запросы к базам данных MASSIVE EAV. Любой, кто говорит, что составлять отчеты из EAV сложно или невозможно, имеет проблемы 1 из 2, либо у них очень плохо спроектированная система EAV, либо они не понимают, как делать запросы с одной из них. Получить хорошие данные для отчетов из EAV DB довольно легко, если вы сделали это несколько раз. Там нет необходимости для базы данных отчетов или что-то особенное, только несколько хороших запросов.

Если вы создаете EAV DB, потратьте немало времени на ее разработку, проект будет либо создавать, либо разрушать ваше приложение, и это будет кошмар, пытающийся исправить или справиться с плохо спроектированным.