Как преодолеть недостатки в отчетности из базы данных EAV?
Кажется, что основные недостатки, связанные с проектами баз данных 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, так как я могу сделать один запрос. В нормализованном дизайне мне приходится выполнять по одному запросу на поле, чтобы избежать объединения массивного декартового произведения.
4 ответа
Краткий ответ - да, база данных отчетов - это разумный подход к решению проблем отчетности из модели данных EAV.
Я потратил несколько лет, работая с решением для управления информацией, которое давало конечным пользователям полную свободу в определении своей собственной модели данных, причем схема и данные сохранялись с использованием модели EAV. Интересно, что этот продукт предоставлял объекты мета-схемы, используемые для выполнения требований отчетности (например, графики для обеспечения навигации по объектам, представления для выполнения проекции и т. Д.). Это означало, что конечный пользователь мог свободно определять запросы, используя те же термины и понятия, которые они использовали для построения модели данных в первом случае. Акт отчетности заключался в том, чтобы вычислить набор данных с помощью этих определений и передать результат традиционному инструменту написания отчетов, как если бы это были реляционные данные.
Одной из сильных сторон этого подхода было то, что тот же механизм, который уже был создан для преобразования модели EAV в нечто, с чем пользователь мог работать, можно повторно использовать и применять к функции отчетности.
В этой схеме сначала мы придумали систему, которая позволяет пользователям хранить любые данные, независимо от их структуры и независимо от предполагаемого будущего использования. Затем, когда пришло время получать отчеты, мы должны выяснить, что у нас есть, и как это связано с тем, что нам нужно.
Поскольку вы четко объясняете природу проблемы "нахождением в этой схеме", мне действительно кажется, что проблема с EAV действительно связана с EAV как таковым.
На самом деле, если подумать: "система, которая позволяет пользователям хранить любые данные" - это эквивалент системы, которая позволяет пользователям просто определять свои relvars. Но какая часть этой системы позволяет пользователям определять ограничения для каждого атрибута? Ой, толпа EAV, кажется, пропустила не столь незначительный аспект управления данными, кажется...
Проблема с EAV не связана с EAV как таковым. Это связано с проектированием и построением базы данных без понимания того, каковы требования к данным на самом деле, и какова логическая структура данных для их соответствия. EAV и любая другая система, которая позволяет пользователям создавать свои собственные данные, ставит это с ног на голову.
В этой схеме сначала мы придумали систему, которая позволяет пользователям хранить любые данные, независимо от их структуры и независимо от предполагаемого будущего использования. Затем, когда пришло время получать отчеты, мы должны выяснить, что у нас есть, и как это связано с тем, что нам нужно.
Удачи с этим.
С EAV проблем нет. Я провожу довольно много времени, запрашивая базы данных MASSIVE EAV. Любой, кто говорит, что составлять отчеты из EAV сложно или невозможно, имеет проблемы 1 из 2, либо у них очень плохо спроектированная система EAV, либо они не понимают, как запрашивать данные из одной системы. Получить хорошие данные для отчетов из EAV DB довольно легко, если вы сделали это несколько раз. Там нет необходимости для базы данных отчетов или что-то особенное, только несколько хороших запросов.
Если вы создаете EAV DB, потратите немало времени на ее разработку, проект будет либо создавать, либо разрушать ваше приложение, и это будет кошмар, пытающийся исправить или справиться с плохо спроектированным.