Diseño de Tabla de Entidad-Atributo-Valor

Actualmente estoy diseñando una estructura de database 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 types de productos con un número infinito de attributes diferentes.

Por ejemplo, los attributes de una computadora portátil serían RAM, tamaño de pantalla, peso, etc. Los attributes 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 set de attributes
  • El set de attributes contiene attributes 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 date)

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

  • Seleccione un producto
  • El producto pertenece al set de attributes
  • El set de attributes contiene attributes 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

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 database haga lo que realmente hace bien, lo que ayuda a dar un context adecuado a los diferentes attributes 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 attributes 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 attributes del producto.

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

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

  3. Reglas de impulso para algo (por ejemplo, fijación de precios) en function de combinaciones de attributes / 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 types diferentes de productos, porque siempre tiene que regresar al esquema para jugar con él para permitir nuevas categorías de productos o types de attributes. .

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 attributes, es posible que desee imponer restricciones, como "debe ser un número" o "debe provenir de esta list {…}". Eso depende de la importancia de la consistencia de los attributes 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.

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 database EAV de Magento ? Sí, puede ser lento, las consultas pueden ser enormes, pero para nosotros las ventajas son más que less. Y, por otro lado, magento se encarga de las consultas.

Estamos en medio de una migration 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.

Sí, normalmente hay una gran penalización al armar las consultas para un model de EAV. Hay mayores penalizaciones de performance 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 layout de database más ortodoxo, según lo recomendado por Oded en los comentarios, el DBMS asegura que los datos en la database sean más consistentes. Yo recomendaría fuertemente el uso de un layout regular (sin EAV).