Entity-Attribute-Value Table Design

Question

Actualmente estoy diseñando una estructura de base de datos para la sección de productos de una plataforma de comercio electrónico. Debe diseñarse de tal forma que permita vender un número infinito de diferentes tipos de productos con un número infinito de atributos diferentes.

E.g. Los atributos de una computadora portátil serían RAM, Tamaño de pantalla, Peso, etc. Los atributos de un libro serían Autor, ISBN, Editor, etc.

Parece que una estructura EAV sería la más adecuada.

• Seleccionar un producto
• producto forma parte de atributo de
• conjunto atributo contiene atributos x e y
  • Attribute x es de tipo de datos de fecha y hora (valores almacenados en attribute_values_datetime)
  • Atributo y es de datos escriba int (valores almacenados en attribute_values_int)
• Definición de cada atributo deno tes del tipo (i, e, x tiene tipo de columna -> DateType)

Asumiendo lo anterior, podría unirse a la selección de la tabla attribute_values_datetime para obtener los datos correctos sin obtener el conjunto de resultados y la construcción de una segunda consulta ahora que la mesa es conocida? Habría un gran impacto en el rendimiento construyendo una consulta de este tipo o sería el siguiente ser más adecuado (aunque menos funcional)

• Seleccionar un producto
• producto pertenece al conjunto de atributos
• conjunto atributo contiene atributos x e y
  • Attribute x es de tipo de datos de fecha y hora pero almacena como texto en attribute_values ​​
  • Atributo y se tipo de datos int sino que se almacena como texto en attribute_values ​​

Answer 1

Voy a ofrecer una opinión contraria a la mayoría de los comentarios sobre esta pregunta. Mientras que EAV es EVIL por todos los motivos que puede encontrar ampliamente explicados muchas veces aquí en SO y DBA.SE y en otros lugares, hay una aplicación muy común para la que la mayoría de las cosas que son incorrectas con EAV son en gran medida irrelevantes y las (pocas) ventajas de EAV son muy pertinentes. Esa aplicación es catálogos de productos en línea.

El principal problema con EAV es que no permite que la base de datos haga lo que es realmente bueno haciendo, que está ayudando a dar contexto adecuado a los diferentes atributos de la información acerca de las diferentes entidades organizándolos en un esquema. Tener un esquema brinda muchas, muchas ventajas en cuanto al acceso, la interpretación y el cumplimiento de la integridad de sus datos.

El hecho de los catálogos de productos es que los atributos de un producto son casi totalmente irrelevantes al sistema de catálogo sí mismo. Los sistemas de catálogo de productos hacen (como máximo) tres cosas con atributos del producto.

1. Muestra los atributos del producto en una lista para los usuarios finales con el siguiente formato: {attribute name}: {attribute value}.

2. mostrar los atributos de varios productos en una cuadrícula de comparación en la que los atributos de los diferentes productos que se alinean uno contra el otro (los productos son por lo general las columnas, atributos son generalmente filas)

3. reglas Drive para algo (por ejemplo, la fijación de precios) en base en combinaciones particulares de atributo/valor.

Si todo el sistema hace es regurgitan la información que es semánticamente irrelevante (al sistema), entonces el esquema para esta información es básicamente inútil. De hecho, el esquema se interpone en el camino en un catálogo de productos en línea, especialmente si su catálogo tiene muchos tipos diferentes de productos, porque siempre tiene que volver al esquema para jugar con él para permitir nuevas categorías de productos o tipos de atributos.

Debido a cómo se usa, incluso el tipo de datos de un valor de atributo en un catálogo de productos no es necesariamente (vital) importante. Para algunos atributos, es posible que desee imponer restricciones, como "debe ser un número" o "debe provenir de esta lista {...}". Eso depende de la importancia de la consistencia de los atributos en su catálogo y de lo elaborado que desee que sea su implementación. Al mirar los catálogos de productos de varios minoristas en línea, diría que la mayoría están preparados para cambiar la simplicidad por consistencia.

Sí, EAV es malo, excepto cuando no lo es.

Answer 2

No sé si esto debería ser un comentario o una respuesta. Sin embargo, aquí voy.

No sé exactamente qué estás construyendo. ¿Pero echó un vistazo al Magento EAV database structure? Sí, puede ser lento, las consultas pueden ser enormes, pero para nosotros las ventajas son más que menos. Y, por otro lado, magento se ocupa de las consultas.

Estamos en el medio de una migración de nuestra tienda en línea (tienda de tamaño medio-grande) para usar Magento y por ahora estamos muy contentos con el enfoque de EAV.

Answer 3

Sí, normalmente existe una gran penalización al armar las consultas para un modelo de EAV. Hay mayores penalizaciones de rendimiento para verificar la autoconsistencia de los datos, porque el DBMS no podrá hacerlo por usted. Si algo sale mal, el DBMS no puede decírselo.

Con un diseño de base de datos más ortodoxo, según lo recomendado por Oded en los comentarios, el DBMS asegura que los datos en la base de datos sean más consistentes. Yo recomendaría fuertemente el uso de un diseño regular (sin EAV).