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

Question

Las principales deficiencias con diseños de bases de datos entidad-atributo-valor en SQL todos parecen estar relacionados con ser capaz de consulta e información de los datos de manera eficiente y rápida. La mayor parte de la información que leí sobre el tema advierten contra la implementación de EAV debido a estos problemas y el carácter común de consultas / informes para casi todas las aplicaciones.

Actualmente estoy diseñando un sistema en el que los campos para una de las entidades no se conocen en el diseño / tiempo de compilación y están definidos por el usuario final del sistema. EAV parece una buena opción para este requisito, pero debido a los problemas que he leído sobre, estoy indeciso en su aplicación ya que también hay algunos bastante los requisitos de información para dicho sistema, así pesada. I pensar He llegado con una forma de evitar esto, pero me gustaría plantear 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 la ejecución de informes, una práctica bien parece ser que tiene un "informe" de base de datos (OLAP), donde los datos de la base de datos normalizada se copian a, indexado extensivamente, y posiblemente desnormalizado para consultas más fácil. La misma idea podría ser utilizado para el trabajo en torno a las deficiencias de un diseño EAV?

El principal inconveniente que veo son la mayor complejidad de la transferencia de los datos de la base de datos EAV a la presentación de informes, ya que puede llegar a tener que alterar las tablas en la base de datos de informes como los nuevos campos se definen en la base de datos EAV. Pero eso es casi imposible y parece ser una solución de compromiso aceptable para la mayor flexibilidad de diseño propuesta por el EAV. Este inconveniente también existe si uso una tienda no es de SQL de datos (es decir, CouchDB o similar) para el almacenamiento de datos principal ya que todas las herramientas de informes estándar están esperando un servidor SQL de consulta contra.

¿Los problemas con los sistemas de EAV sobre todo a desaparecer si usted tiene una base de datos de informes por separado para realizar consultas?

EDIT: Gracias por los comentarios hasta el momento. Una de las cosas importantes sobre el sistema que estoy trabajando en eso que estoy realmente sólo hablando acerca del uso de EAV para una de las entidades, no todo en el sistema.

Toda la esencia del sistema es capaz de extraer datos de múltiples fuentes dispares que no se conocen de antemano y crujir los datos para llegar a algunos "más conocido" datos sobre una entidad en particular. Así que cada "campo" Estoy tratando es de varios valores y también estoy obligado a realizar un seguimiento de la historia de cada uno. El diseño normalizado para esto termina siendo 1 mesa por campo lo que hace que la consulta es como que de todos modos dolorosa.

Estos son los esquemas de tablas y datos de la muestra que estoy viendo (claramente diferente de lo que estoy trabajando, pero creo que ilustra bien el 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 -
----------------------------------------------------------------------------------------

Normalizado Diseño

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 utilizando 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 tira todos los datos sobre una persona para todos los campos para que pueda generar la grabar para la tabla de informes. Esto es en realidad más fácil en el modelo EAV como lo puede hacer una sola consulta. En el diseño normalizado, me acaban de tener que hacer 1 consulta por campo para evitar un producto cartesiano masiva de unirse a todos juntos.

Answer 1

Breve respuesta -. Sí, una base de datos de informes es un enfoque razonable para la solución de los problemas de la presentación de informes a partir de un modelo de datos EAV

Me 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 proporcionado meta-esquema de objetos utilizados para cumplir con los requisitos de información (por ejemplo los gráficos para proporcionar una navegación objeto, vistas para llevar a cabo la proyección, etc.). Esto significaba que el usuario final es libre de definir consultas utilizando los mismos términos y conceptos que se había usado para construir el modelo de datos en primer lugar. El acto de presentación de informes era esencialmente para calcular el conjunto de datos mediante la navegación estas definiciones, y entregar el resultado a una herramienta tradicional informe escrito como si se tratara de datos relacionales.

Uno de los puntos fuertes de este enfoque es que el mismo mecanismo que ya estaba en su lugar de transformar el modelo EAV a algo que el usuario pueda trabajar con podrían ser reutilizados y se aplica a la función de informe.

Answer 2

  

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 llega el momento de obtener los informes a cabo, tenemos que averiguar lo que 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 de ella: "un sistema que permite a los usuarios almacenar cualquier tipo de datos en absoluto" es el equivalente de un sistema que permite a los usuarios simplemente definir sus relvars. Pero, ¿qué parte de ese sistema permite a los usuarios definir restricciones sobre cada atributo? Vaya, la multitud EAV parece haber pasado por alto un aspecto no tan poco importante de la gestión de datos, parece ...

Answer 3

El problema con EAV no se debe a EAV como tal. Es debido al diseño y construcción de una base de datos sin entender lo que los requisitos de datos realmente son, y qué estructura lógica de los datos deben tener a fin de cumplir con estos requisitos. EAV, y cualquier otro sistema que permite a los usuarios diseñar sus propios datos, convierte a esta en su cabeza.

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 llega el momento de obtener los informes a cabo, tenemos que averiguar lo que tenemos, y cómo se relaciona con lo que necesitamos.

Buena suerte con eso.

Answer 4

No hay ningún problema con EAV me paso una cantidad bastante grande de tiempo de consulta de bases de datos EAV masivo. Cualquier persona que dice la presentación de informes de EAV es difícil o imposible tiene 1 de 2 problemas, ya sea que tenga un sistema de EAV muy mal diseñado o que no entienden cómo a consulta desde una. conseguir buenos datos del informe-poder de una EAV DB es bastante fácil una vez que lo ha hecho un par de veces. No hay necesidad de una base de datos de informes especiales o nada, a sólo unas pocas preguntas buenas.

Si usted está construyendo una base de datos EAV pasar mucho tiempo el diseño de ella, el diseño va a hacer o deshacer su solicitud y será una pesadilla tratando de arreglar o hacer frente a una mal diseñado.