¿Cómo superar las deficiencias en los informes de la base de datos EAV?

Question

Las principales deficiencias con los diseños de base de datos Entidad-Valor-Atributo en SQL parecen estar relacionadas con la capacidad de consultar e informar sobre los datos de manera eficiente y rápida. La mayoría de la información que leo sobre el tema advierte contra la implementación de EAV debido a estos problemas y la coincidencia de consultas/informes para casi todas las aplicaciones.

Actualmente estoy diseñando un sistema en el que los campos de una de las entidades no se conocen en el momento del diseño/compilación y los define el usuario final del sistema. EAV parece una buena opción para este requisito, pero debido a los problemas que he leído, tengo dudas en su implementación, ya que también hay algunos requisitos de informes bastante pesados ​​para este sistema. I think He encontrado una forma de evitar esto, pero me gustaría formular la pregunta a la comunidad SO. Dado que la base de datos normalizada típica (OLTP) todavía no es siempre la mejor opción para ejecutar informes, una buena práctica parece ser tener una base de datos de informes (OLAP) donde se copian los datos de la base de datos normalizada indexado extensamente, y posiblemente desnormalizado para facilitar la consulta. ¿Se podría usar la misma idea para solucionar las deficiencias del diseño de un EAV?

La principal desventaja que veo es la mayor complejidad de transferir los datos de la base de datos EAV a los informes ya que puede terminar alterando las tablas en la base de datos de informes cuando se definen nuevos campos en la base de datos EAV. Pero eso no es imposible y parece ser una solución aceptable para la mayor flexibilidad que ofrece el diseño de EAV. Esta desventaja también existe si utilizo un almacén de datos que no son SQL (es decir, CouchDB o similar) para el almacenamiento de datos principal, ya que todas las herramientas de informes estándar esperan que un servidor SQL consulte.

¿Los problemas con los sistemas EAV generalmente desaparecen si tiene una base de datos de informes separada para realizar consultas?

EDIT: Gracias por los comentarios hasta el momento. Una de las cosas más importantes sobre el sistema en el que estoy trabajando es que solo estoy hablando de usar EAV para una de las entidades, no de todo en el sistema.

La esencia del sistema es poder extraer datos de múltiples fuentes diferentes que no se conocen con anticipación y analizar los datos para obtener algunos datos "más conocidos" sobre una entidad en particular. Así que cada "campo" con el que estoy tratando tiene múltiples valores y también estoy obligado a seguir el historial de cada uno. El diseño normalizado para esto termina siendo 1 tabla por campo, lo que hace que consultarlo sea algo doloroso de todos modos.

Éstos son los esquemas de tablas y datos de ejemplo que estoy viendo (claramente diferente de lo que estoy trabajando, pero creo que ilustra el pozo punto):

Tablas 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 - 
------------------------------------------------------------------- 

Tabla de información

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

Diseño normalizado

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 - 
------------------------------------------------------ 

El campo "confianza" que aquí se genera usando la lógica de que no se puede expresar con facilidad (en su caso) utilizando SQL así que mi operación más común además de la inserción de nuevos valores se tiran todos los datos sobre una persona para todos los campos para que pueda generar el registro para la tabla de informes.Esto es en realidad más fácil en el modelo EAV ya que puedo hacer una sola consulta. En el diseño normalizado, termino teniendo que hacer 1 consulta por campo para evitar que un producto cartesiano masivo los una a todos.

Answer 1

Respuesta corta - sí, una base de datos de informes es un enfoque razonable para resolver los problemas de informes de un EAV modelo de datos.

pasé varios años trabajando con una solución de gestión de la información que permitió a los usuarios finales una completa libertad para definir su propio modelo de datos, tanto con el esquema y los datos almacenados usando un modelo EAV. Curiosamente, este producto proporcionó objetos de meta-esquema utilizados para cumplir los requisitos de informes (por ejemplo, gráficos para proporcionar navegación de objetos, vistas para realizar proyecciones, etc.). Esto significaba que el usuario final era libre de definir consultas utilizando los mismos términos y conceptos que habían utilizado para construir el modelo de datos en primera instancia. El acto de informar fue esencialmente para calcular el conjunto de datos navegando por estas definiciones, y entregar el resultado a una herramienta de redacción de informes tradicional como si se tratara de datos relacionales.

Uno de los puntos fuertes de este enfoque fue que el mismo mecanismo que ya estaba en su lugar para transformar el modelo de EAV a algo con lo que el usuario podría trabajar podría reutilizarse y aplicarse a la función de informe.

Answer 2

El problema con EAV no se debe a EAV como tal. Se debe al diseño y construcción de una base de datos sin comprender cuáles son realmente los requisitos de datos, y qué estructura lógica deben tener los datos para cumplir con estos requisitos. EAV, y cualquier otro sistema que permita a los usuarios diseñar sus propios datos, lo convierte en un problema.

En este esquema, en primer lugar nos encontramos con un sistema que permite a los usuarios almacenar cualquier tipo de datos en absoluto, independientemente de su estructura, y con independencia del futuro uso previsto. Luego, cuando llegue el momento de sacar los informes, tenemos que descubrir qué tenemos y cómo se relaciona con lo que necesitamos.

Buena suerte con eso.

Answer 3

En este esquema, primero se presenta un sistema que permite a los usuarios almacenar cualquier clase de datos, independientemente de su estructura, y sin importar el futuro uso previsto. Luego, cuando llegue el momento de sacar los informes, tenemos que descubrir qué tenemos y cómo se relaciona con lo que necesitamos.

Desde atribuye claramente la naturaleza del problema a "estar en este esquema", lo que realmente me parece como si el problema con EAV realmente es debido a la EAV como tal.

De hecho, ahora que lo pienso: "un sistema que permite a los usuarios almacenar cualquier clase de datos" es el equivalente de un sistema que permite a los usuarios simplemente definir sus actualizaciones. Pero, ¿qué parte de ese sistema permite a los usuarios definir restricciones en cada atributo? Vaya, la multitud EAV parece haber perdido un aspecto no tan importante de la gestión de datos, parece ...

Answer 4

No hay ningún problema con EAV me paso una cantidad bastante grande de tiempo consultar las bases de datos EAV masivo. Cualquiera que diga que informar desde EAV es difícil o imposible tiene 1 de 2 problemas, ya sea que tengan un sistema EAV muy mal diseñado o que no entiendan cómo consultar desde uno. obtener buenos datos reportables desde un EAV DB es bastante fácil una vez que lo haya hecho varias veces. No hay necesidad de una base de datos de informes ni nada especial, solo unas pocas buenas consultas.

Si está construyendo un EAV DB, dedique MUCHO tiempo a diseñarlo, el diseño hará o interrumpirá su aplicación y será una pesadilla tratar de arreglarlo o tratarlo con uno mal diseñado.