EAV alternativo, estructura base?

¡Buen día!


En la tienda en línea hay una pregunta sobre los parámetros adicionales de los productos. Parámetros del número finito. Muchos tipos de bienes. Lo primero que viene a la mente es la arquitectura ejemplar de EAV. En Internet, escriben que esto es malo y una alternativa: para cada tipo de producto para crear su propia tabla en la base de datos.


Me gustaría saber qué es lo mismo. Las verdaderas razones, no ficticias, de que "no trabajo". Y vea la estructura de la base de datos, cómo trabajar con ella si hace su propia tabla para cada tipo de producto. Cómo mostrar, por ejemplo, todos los productos en stock. O todos los productos son rojos. Si hay varias tablas para cada tipo de producto ... no puedo pensar en un esquema óptimo.


Usado ms sql 2008.


Y sin embargo ... inicialmente conozco todos los parámetros posibles, es decir, Habrá 2 tablas ... Productos y Descriptores de productos en los que se escriben ProductID (int), DescriptorID (int), DescriptorValue (str). Y sé qué ID implica en la etapa de creación. Es decir Esta no es una tienda en línea para productos abstractos, pero conozco los productos. Por ejemplo, DescriptorID = 7 es responsable del color del televisor ...

y lo que no le gusta a la EAB? - chelsea murray
¿Y es posible con más detalle a medida que se aplica y está en construcción? - brooke mckenna
Después de una pequeña caminata en Google, se me ocurrió la idea de que EAB es solo EAV en transliteración.

¿Qué no se puede arreglar EAV? El rendimiento es el único problema. - bill patterson
y cuál es el problema de rendimiento? 1 tabla más para los parámetros del producto ... - barbarallen mullins
¿perdona el rendimiento de las consultas que no le convienen? - sherry dinkins
Respuestas
leanna
Por lo general, para las tiendas en línea, la estructura de EAV es aproximadamente la siguiente:
Categoría (* - *) Opción (1 - *) Valor (* - 1) Producto
La búsqueda de productos, por ejemplo, se realiza a través de INNER JOIN y crea grandes gastos generales. Esta es la única desventaja y bastante significativa de este enfoque. Se resuelve utilizando vistas en la base de datos, o soluciones NoSQL. También hay opciones para usar la búsqueda de facetas, por ejemplo a través de Sphinx. Pero la flexibilidad de diseño es bastante grande para mí.

En su caso, si implementa su versión con una tabla de descriptores, obtendrá la siguiente estructura:
Artículo (* - *) Valor (1 - *) Manija.
Además, si conoce los valores del descriptor, entonces es lógico decir esto en ENUM o algo más. De hecho, no es un modelo EAV, es solo una de esas alternativas.

La búsqueda por dicha estructura también se implementará a través de INNER JOIN (aunque puede ser diferente, pero en teoría todo depende solo de los índices, y el método de búsqueda no tiene un rendimiento muy diferente) y aún será más lento que a través de una vista o solo desde una tabla.
rosalie
link. En las pruebas, 250 mil productos con 10 mil parámetros (10 parámetros por producto) funcionan en menos de 1 ms por posgresql, por lo que la base no será el lugar más importante.

& gt; Me gustaría saber qué está mal después de todo.
No hay nada malo con EAV. Si se asignan suficientes recursos de hardware para el tamaño base actual y los índices se colocan normalmente en la base de datos, entonces la base claramente no es la base. Así que los "asesores" que, sin argumentos concretos, lo dicen, pueden enviarlos inmediatamente al bosque con calma.
¿Qué significa "hacer ejercicio"? Solicitud en caché o no? ¿Se comparó la velocidad con una muestra de una tabla regular? Más detalles por favor.
Les digo por experiencia que EAV es un freno monstruoso. Y en teoría, después de escuchar el curso www.db-class.org/course/auth/welcome, puedo agregar que EAV es una perversión en general sobre la idea de las bases de datos relacionales. Si mi opinión no es suficiente, lea aquí: en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model#The_critical_role_of_metadata_in_EAV_systems o aquí: stackoverflow.com/questions/tagged/entity-attribute-value?sort=votes&pagesize=50 o google y lea cómo ahora los autores de Magento están soñando con deshacerse de su EAV elegido.

Yo también respondí al autor y aconsejé bases de datos más adecuadas (Mongo) o una mejor reflexión sobre la estructura de la base de datos, pero aparentemente no quiero movimientos corporales y quiero convencerme contra el sentido común (lo que el autor percibe definitivamente, de lo contrario no lo pediría) - mike ruff
"cumple" significa ejecutar una consulta de SQL.
 
=> SELECT COUNT(*) FROM goods;
 count
--------
 250000
(1 row)
=> SELECT COUNT(*) FROM goods_option;
 count
-------
 10000
(1 row)
=> SELECT COUNT(*) FROM goods_option_link;
  count
---------
 2500000
(1 row)

EXPLICAR ANALIZAR muestra. que la solicitud para recibir una tarjeta de un producto específico (con 10 parámetros) toma ~ 0.15 ms La parte de PHP piensa que más de lo que la solicitud se maneja en postgresql-e.

No escuché ningún curso inteligente. Soy ingeniero y resuelvo problemas específicos en condiciones específicas. Las empresas no están interesadas en estos problemas técnicos. Pero los representantes de negocios quieren cualquier tipo de productos con cualquier conjunto de características y para que cuando aparezca un nuevo tipo, no sea necesario atraer a los desarrolladores que conjurarán algo allí en la estructura de las tablas. Y, por supuesto, esto debería funcionar rápidamente y sin fallar al mismo tiempo que aumenta el catálogo a un millón de posiciones.
Así que resuelvo estos problemas. Por lo tanto, tengo un motor PHP simple que mantiene el flujo de 300 solicitudes / seg desde el tiempo de generación de la página de ~ 0.015 seg por un tiempo prolongado (es decir, ~ 25 millones por día). En un segmento de 5 segundos, pudo manejar un aumento de carga a corto plazo de hasta 1000 solicitudes / seg con la generación
 páginas ~ 0.070 seg. En este caso, la parte de PHP consume menos de 200 MB de RAM. En general, todo el paquete de nginx + php-fpm + postgresql + redis come ~ 1-1.5 GB.

Si las condiciones de mañana cambian, eso demuestra que EAV no me conviene, aplicaré una estructura más óptima sin ningún problema. Y ciertamente nunca seré un fanático religioso escandaloso:% username%,% lang% shit y% struct% un monstruo monstruo porque soy ingeniero y profesional. Y el criterio de adecuación para mí es la implementación efectiva de la tarea, y no los argumentos abstractos de los teóricos. - susan procter
Solicitud de código de risa, gracias. Después de esto, nada que discutir contigo, lo siento. - kristall driggers
alekciy, usted ha demostrado el caso degenerado de EAV. En su caso, el concepto de entidad está degenerado porque está representado por una tabla separada. Tales estructuras se denominan UDA (atributos definidos por el usuario) y, de hecho, no hay nada terrible en ellas. En el sentido de que en este modelo todavía es posible usar bases de datos para el control de integridad, en contraste con el EAV clásico, donde la integridad debe garantizarse de manera independiente, y en condiciones de acceso competitivo es una tarea muy importante, y resolverla de manera más eficiente que el DBMS. para el modelo relacional clásico, a veces, es simplemente imposible.

Sin embargo, la aplicabilidad de este enfoque tiene varias limitaciones en las que, obviamente, encajas. Pero en su caso particular, creo que es demasiado pronto para generalizar. De hecho, no es un problema recibir una tarjeta para un solo producto utilizando esta estructura. Pero para presentar la jerarquía de productos en forma de tabla ya es un problema grave, debe realizar tantas uniones como los atributos definidos por la entidad. Si necesita seleccionar solo un atributo o varios, aplicando el operador OR a los predicados, entonces tampoco hay problemas. Pero si necesita seleccionar por los valores de varios atributos, aplicando el operador AND a los predicados de selección, esto se vuelve muy problemático. También vale la pena señalar que con este enfoque, la lógica de la aplicación no puede usar los atributos definidos por el usuario. Desde que en el ciclo de vida de la aplicación, el código de atributo puede ser cambiado por el usuario.

Pero el hecho de que realmente no haya nada terrible en EAV y en UDA, estoy completamente de acuerdo con usted. Solo estas estructuras tienen un alcance limitado. Y si el UDA aún se puede utilizar en algún lugar, entonces el alcance del EAV es insignificante. Estas son aplicaciones que trabajan con entidades separadas, modificadas en el modo de acceso exclusivo. Me parece que esta área es estrecha en la tabla, que el caso para el cual es aplicable el enfoque EAV es bastante excepcional. - rikke
& gt; De hecho, obtener una tarjeta de un solo elemento utilizando esta estructura no es un problema.
Jerarquía en una tabla separada en forma de AL o NS según la situación. Comunicación con el product-list_tree a través de la tercera tabla. Esto cubre los requisitos comerciales actuales. En particular, no se requiere una búsqueda por atributos específicos; para una tienda de ropa en línea, la lógica de búsqueda "Quiero una camisa roja de tamaño XX" generalmente resulta en una selección rápida de camisetas con un índice y más lenta, pero dentro de una aplicación, un filtrado rápido por valores de atributo. Esto es más que cumple con los requisitos actuales y con un amplio margen. Si fuera un catálogo de equipos informáticos con una búsqueda frecuente de un conjunto de atributos, entonces, por supuesto, esta estructura no se usaría.

Gracias por la punta en UDA. - susan lundstedt
susan rodgers
En general, la mejor alternativa a EAV es la base sin esquemas, la misma MongoDB, por ejemplo. Otra opción es usar SQL (EAV o tablas separadas) + un motor de búsqueda sin esquema (por ejemplo, elasticsearch).