Estoy diseñando un sitio de comercio electrónico multilingüe. Los productos tienen diferentes propiedades. Algunas propiedades son diferentes para cada idioma (como el color), otras propiedades son las mismas para todos los idiomas (como SKU). Las propiedades no están predefinidas, por ejemplo, los automóviles tienen otras propiedades que las máquinas de espresso.¿Qué es un diseño de esquema MongoDB eficiente para un sitio de comercio electrónico multilingüe?
me gustaría diseñar el esquema de base de tal manera que:
- Búsqueda y representación de todos los productos de la categoría X en el lenguaje y es rápido
- La cantidad de datos duplicados es baja
- Pongo 't desea utilizar archivos con traducciones
estoy pensando en usar un esquema como éste:
{
_id: ObjectID("5dd87bd8d77d094c458d2a33"),
multi-lingual-properties: ["name", "description"],
name: { en: "Super fast car",
nl: "Hele snelle auto"},
description: { en: "Buy this car",
nl: "Koop deze auto"},
price: 20000,
sku: "SFC106X",
categories: [ObjectID("4bd87bd8277d094c458d2a43")]
}
¿Existe una mejor alternativa a este esquema? ¿Qué problemas encontraré cuando use este esquema?
En mi experiencia, los sistemas de comercio electrónico tienden a tener esquemas de bases de datos altamente relacionales. ¿Estás seguro de que MongoDB es adecuado para esto? –
@Neville K Sí: http://spf13.com/post/mongodb-ecommerce-a-perfect-combination y http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/ –
Estoy totalmente preparado para aceptar que soy un viejo cabrón cínico, pero el hecho de que los defensores de MongoDB estén a favor de MongoDB en este contexto no sería suficiente para convencerme. Me gusta bastante la idea de NoSQL para la parte de catálogo de un sitio de comercio electrónico: los productos son notoriamente polimórficos. No estoy seguro de querer hacer la parte de lógica de negocios: compra, salida, pago, dirección, cumplimiento, sin mi cobija de comodidad relacional ... –