mysql - multivaluados - modelo relacional

Diseño de Tabla de Entidad-Atributo-Valor

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.

Por ejemplo, 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.

• Seleccione un producto
• El producto pertenece al conjunto de atributos
• El conjunto de atributos contiene atributos xey
  • El atributo x es el tipo de datos datetime (valores almacenados en attribute_values_datetime)
  • El atributo y es el tipo de datos int (valores almacenados en attribute_values_int)
• Cada definición de atributo denota el tipo (i, e, x tiene tipo de columna -> tipo de fecha)

Suponiendo lo anterior, ¿podría unirme a la selección de la tabla attribute_values_datetime para obtener los datos correctos sin obtener el conjunto de resultados y generar una segunda consulta ahora que se conoce la tabla? ¿Habría un gran golpe de rendimiento al construir una consulta de este tipo o sería más apropiado el siguiente (aunque menos funcional)?

• Seleccione un producto
• El producto pertenece al conjunto de atributos
• El conjunto de atributos contiene atributos xey
  • El atributo x es el tipo de datos datetime pero se almacena como TEXTO en attribute_values
  • El atributo y es tipo de datos int pero se almacena como TEXTO en attribute_values

Answer 1

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

No sé exactamente qué estás construyendo. Pero, ¿has echado un vistazo a la estructura de la base de datos EAV de Magento ? 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 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 2

Sí, normalmente hay 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, como recomienda 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).

Answer 3

Voy a ofrecer una opinión contraria a la mayoría de los comentarios sobre esta pregunta. Aunque EAV es MALO por todas las razones que puede encontrar ampliamente explicadas muchas veces aquí en SO y DBA.SE y en otros lugares, hay una aplicación realmente común para la que la mayoría de las cosas que son incorrectas con EAV son en gran parte irrelevantes y ( 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 realmente hace bien, lo que ayuda a dar un contexto adecuado a los diferentes atributos de la información sobre las diferentes entidades al organizarlas 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 para el sistema de catálogo en sí. Los sistemas de catálogo de productos hacen (como máximo) tres cosas con atributos del producto.

1. Muestre los atributos del producto en una lista a los usuarios finales en la forma: {nombre del atributo}: {valor del atributo}.

2. Muestre los atributos de múltiples productos en una grilla de comparación donde los atributos de diferentes productos se alinean entre sí (los productos generalmente son columnas, los atributos son generalmente filas)

3. Reglas de impulso para algo (por ejemplo, fijación de precios) en función de combinaciones de atributos / valores particulares.

Si todo lo que su sistema hace es regurgitar información que es semánticamente irrelevante (para el sistema), entonces el esquema para esta información es básicamente inútil. De hecho, el esquema se interpone en un catálogo de productos en línea, especialmente si su catálogo tiene muchos tipos diferentes de productos, porque siempre debe volver al esquema para retocarlo con el fin de 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 (vitalmente) 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.