¿Debo usar el modelo EAV?

Question

Estoy diseñando mi base de datos/dominio para una aplicación de comercio electrónico y estoy teniendo dificultades para descubrir cómo almacenar productos.

El sitio web venderá una amplia gama de productos, bolígrafos, tangas, tatuajes, paraguas, todo. Cada uno de estos productos compartirá algunos atributos comunes: alto, ancho, largo, peso, etc. pero algunos productos tienen datos especiales. Por ejemplo, las plumas tienen diferentes colores de tinta y las puntas/tapas y folletos pueden tener diferentes tipos de pliegues. Hasta ahora, he pensado en más de 20 atributos adicionales, pero estos atributos solo pueden aplicarse al 1% de los productos en el sitio web.

Así que me pregunto si es apropiado implementar un modelo de EAV para manejar los datos adicionales. Teniendo en cuenta que cuando los clientes están viendo el sitio en la interfaz, habrá una barra lateral de filtrado como eBay y carsales.com.au. (Por lo tanto, teniendo en cuenta que habrá un poco de consultas)

No creo que sea práctico implementar la herencia de Class Table ya que el sistema debe seguir siendo flexible. Esto se debe a que, en el futuro, podremos tener más atributos con nuevos tipos de productos.

La otra cosa que he considerado es utilizar una base de datos NoSQL (probablemente MongoDB). Sin embargo, tengo poca experiencia con este tipo de bases de datos, ¿incluso resolverá mi problema?

Examen de las opciones:

1. productos entidad individual con un montón de columnas
2. independiente entidad atributos (EAV)
3. Cambiar al esquema menor persistencia

estoy en el proceso de construir un prototipo con una entidad de atributos para ver qué tan flexible es, y probar el rendimiento y qué tan fuera de control obtiene la consulta.

EDIT: Estoy, por supuesto, abierto a cualquier otra solución.

Answer 1

Gran pregunta, pero por supuesto, no hay "una sola manera verdadera". Según @BenV, Magento usa el modelo EAV. Mi experiencia con esto ha sido abrumadoramente positiva, sin embargo, hace tropezar a otros usuarios. Algunas consideraciones:

1. Rendimiento. EAV requiere combinaciones complejas de tablas múltiples para rellenar su objeto con los atributos relevantes. Eso incurre en un golpe de rendimiento. Sin embargo, eso puede mitigarse a través del almacenamiento en caché cuidadoso (en todos los niveles a través de la pila, incluido el almacenamiento en caché de consultas) y el uso selectivo de la desnormalización. Magento permite a los administradores seleccionar un modelo desnormalizado para categorías y productos donde el número de SKU lo justifique (generalmente en miles). Esto, a su vez, requiere observadores que desencadenan una nueva indexación (¡siempre es buena!) Y actualizaciones en las tablas desnormalizadas "planas" cuando cambian los datos del producto. Eso también se puede programar o activar manualmente con un aviso al administrador.

2. 3rd Party Complejidad usuario Si alguna vez va a hacer esta aplicación esté disponible para otros usuarios, muchos encontrarán EAV demasiado complejo y que va a terminar tratando con una gran cantidad de balidos y el abuso desinformados sobre el usuario foros (ref ¡Magento!).

3. Futura extensibilidad y arquitectura de complementos. No hay duda de que el modelo de EAV realmente se hace propio cuando la extensibilidad es un factor. Es muy simple agregar nuevos atributos en el modelo mientras se minimiza el riesgo de romper el ORM existente y el código del controlador.

4. Cambios en el tipo de datos EAV hace que sea un poco más difícil alterar los tipos de datos de atributos. Si su diseño inicial requiere un tipo de datos de atributo particular que cambie en el futuro (digamos int a varchar), significa que tendrá que migrar todos los registros para ese atributo a la tabla correspondiente que coincida con el nuevo tipo de datos. Por supuesto, los puristas sugerirían que tengas el diseño correcto la primera vez, ¡pero la realidad se entromete a veces!

5. importaciones de productos Manual Una cosa que hace casi imposible EAV es la importación de productos (u otras entidades) en la base de datos utilizando SQL y/o de estilo phpMyAdmin CSV/XML. Tendrá que escribir un módulo de Importador que acepte los datos estructurados y lo pase a través de la capa de Modelo de la aplicación para conservarlo en la base de datos. Eso se agrega a tu complejidad.

Answer 2

El carro de la compra de código abierto Magento permite atributos personalizados para sus productos usando un diseño de EAV. Puede consultar su esquema de base de datos here.

Answer 3

Le sugiero que mire más de cerca en Doctrine 2 ORM con el complemento OXM (https://github.com/doctrine/oxm). Solucionará tu problema con diferentes atributos. Por supuesto, se le pedirá que cree índices para buscar atributos personalizados, pero no creo que sea un problema :)

Si no le importa la cantidad de miembros de la comunidad, puede usar MongoDB también .