Как преодолеть недостатки в создании отчетов от базы данных EAV?
Главные недостатки с проектированиями баз данных Значения атрибута объекта в SQL все, кажется, связаны со способностью запросить и сообщить относительно данных эффективно и быстро. Большая часть информации, которую я считал на предмете, предостерегает от реализации EAV из-за этих проблем и общности запросов/создания отчетов почти для всех приложений.
Я в настоящее время разрабатываю систему, где поля для одного из объектов не известны при дизайне/времени компиляции и определяются конечным пользователем системы. EAV походит на подходящий вариант для этого требования, но из-за проблем я читал о, я колеблюсь в реализации его, поскольку существуют также некоторые довольно тяжелые требования к отчетности для этой системы также. Я думаю, что придумал путь вокруг этого, но хотел бы поставить вопрос к ТАКИМ ОБРАЗОМ сообщество.
Учитывая, что типичная нормализованная база данных (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 -
------------------------------------------------------
Поле "Confidence" здесь сгенерировано с помощью логики, которой нельзя выразить легко (если вообще) использование SQL, таким образом, моя наиболее распространенная операция помимо вставки новых значений будет вытягивать ВСЕ данные о человеке для всех полей, таким образом, я смогу генерировать запись для таблицы отчетов. Это на самом деле легче в модели EAV, поскольку я могу сделать единый запрос. В нормализованном дизайне я заканчиваю тем, что имел необходимость сделать 1 запрос на поле для предотвращения крупного декартова произведения от присоединения к ним всем вместе.
3 ответа
Краткий ответ - да, база данных отчетов - это разумный подход к решению проблем создания отчетов на основе модели данных EAV.
Я провел несколько лет, работая с решением для управления информацией, которое дало конечным пользователям полную свободу определять свою собственную модель данных, причем как схема, так и данные, хранящиеся с использованием модели EAV. Интересно, что этот продукт предоставил объекты метасхемы, используемые для выполнения требований к отчетности (например, графики для обеспечения навигации по объектам, представления для выполнения проекции и т. Д.). Это означало, что конечный пользователь мог свободно определять запросы, используя те же термины и концепции, которые они использовали при построении модели данных в первом случае. Акт создания отчетов заключался в основном в вычислении набора данных путем навигации по этим определениям и передаче результата традиционному инструменту написания отчетов, как если бы это были реляционные данные.
Одной из сильных сторон этого подхода было то, что тот же механизм, который уже существовал для преобразования модели EAV во что-то, с чем пользователь мог бы работать, можно было повторно использовать и применить к функции отчетности.
Проблема с EAV не связана с EAV как таковым. Это связано с тем, что при проектировании и построении базы данных не понимается, каковы на самом деле требования к данным и какую логическую структуру должны иметь данные, чтобы соответствовать этим требованиям. EAV и любая другая система, которая позволяет пользователям создавать свои собственные данные, переворачивает их с ног на голову.
В этой схеме мы сначала придумываем систему, которая позволяет пользователям хранить любые данные, независимо от их структуры и вне зависимости от предполагаемого использования в будущем. Затем, когда пришло время подготовить отчеты, мы должны выяснить, что у нас есть и как это соотносится с тем, что нам нужно.
Удачи с этим.
В этой схеме мы сначала придумываем систему, которая позволяет пользователям хранить любые данные, независимо от их структуры и вне зависимости от предполагаемого использования в будущем. Затем, когда пришло время подготовить отчеты, мы должны выяснить, что у нас есть и как это соотносится с тем, что нам нужно.
Поскольку вы четко приписываете природу проблемы «участию в этой схеме», мне действительно кажется, что проблема с EAV на самом деле связана с EAV как таковым.
На самом деле, если задуматься: «система, которая позволяет пользователям хранить любые данные» - это эквивалент системы, которая позволяет пользователям просто определять свои relvar. Но какая часть этой системы позволяет пользователям определять ограничения для каждого атрибута? Ой, похоже, толпа EAV упустила не такой уж и маловажный аспект управления данными, кажется ...