BBDD relacional tienda online multiartículos

[RCTrek]

Hola,

Estoy trabajando en un projecto de una web de comercio electrónico. La idea es que la web no sea de un único tipo de de artículos, como por ejemplo una tienda de ropa donde todas los artículos tienen las mismas caracterísitcas como son talla y color, si no que sea una tienda en el sentido más general donde se pueda comercializar cualquier tipo de artículos a la vez, como ropa, libros, electrónica, etc y que a priori no se sepan todos los tipos de artículos que se pueden vender.

Estoy encontrando dificultades a la hora de diseñar la BBDD que soporte el sistema para la gestión de stocks y precio de los artículos ya que pueden depender de diferentes variables. Me intento explicar:

Un artículo puede tener, digamos unas propiedades, como para un libro por ejemplo serían autor o en ropa la marca, para cada artículo siempre serán las mismas, pero dependiendo del tipo de artículo tendrá unas u otras. Con lo cual tendríamos la tabla artículo que estaría realacionada N a N con artículo.
También podemos decir que el artículo tiene opciones, que son los parámetros que el comprador puede variar como por ejemplo para la ropa sería talla o color. En principio parece que con hacer una relación N a N entre artículos y opciones bastaría, pero el problema se me presenta que de estas opciones puede depender el precio del artículo y el stock de la misma. Tomando el ejemplo de cualquier tienda de ropa online, una camiseta Roja del modelo X puede tener stock 30 en talla L y 25 en talla XL y la misma camiseta en colo azul, puede valer 5€ más.

Si conociesemos a priori todos los tipos que se van a permitir en el sistema, es decir, ropa, libros, electrónica, bastaría con hacer una especialización de artículos y desglosarlos en diferentes tablas como propiedades_libro, propiedades_ropa, opciones_libro, opciones_ropa, etc...pero la idea inicial es que esto sea personalizable. Es decir, que el usuario que va a dar de alta un artículo pueda seleccionar entre los existentes tipos de producto y si ninguno se adapta al producto que quiere dar de alta tener la posibilidad de crear un nuevo tipo con sus propiedades y opciones particulares. Por ejemplo, quiere añadir cervezas artesanales y solo hay creados los tipos ropa y libros, por lo tanto necesita añadir un nuevo tipo de artículo que tenga las propiedad origen y la opción volumen.

Hasta el momento las ideas que se me han ocurrido son dos:
   1- En la tabla propiedades y opciones añadir N campos como propiedad1...propiedadN y opción1...opciónN, lo cual limitraría por diseño el número de propiedades y opciones por tipo de artículo.
   2- Generar las tablas de forma dinámica, lo cual dará un coste elevado de programación ya que será complicado a la hora de tomar los nombres de los diferentes campos.

Veo peros tanto a uno como al otro.

¿Alguien ha usado alguna vez un sistema similar? ¿Alguien puede aconsejarme como realizar el diseño de la base de datos relacional?

Gracias por adelantado.

[WHK]

Hola, a mi parecer la mejor opción para mi es creando propiedades dinámicas con tablas fijas por temas de escalabilidad, ya que si hoy diseñas una base de datos con todos los campos que necesitarás y después agregas un tipo de producto nuevo, vas a tener que modificar la base de datos y eso no se puede dar.

El tema es que puedes usar una tabla de etiquetas donde cada producto pueda tener múltiples tipos de etiquetas, así como los post de un blog y estas a su ves dentro de una categorización, pero ojo, son solo dos dimensiones y nada más. Te lo digo por experiencia propia porque una ves hice mi propio sistema CMS en php con un sistema integrado de carrito de compras para venderlo en mi país.

Por ejemplo, al momento de crear un nuevo producto en el sistema voy a crear la categoría de etiquetas llamada "colores" y dentro le pongo etiquetas llamadas "rojo", "verde", etc. De esta manera cuando tenga un buscador, puedo discriminar por categoría de etiquetas y por etiquetas, por ejemplo: muéstrame todos los productos de tipo ropa donde el color sea rojo y de talla xl, entonces en la base de datos irá a buscar productos que tengan categoría de etiquetas de tipo productos y el tag "ropa" y a demás que contengan la categoría "colores" y tags de tipo rojo y categoría de tipo talla que tenga la etiqueta xl.

Si te fijas, tengo la tabla productos, una tabla de categoría de etiquetas de productos y una tabla de etiquetas de productos, donde también existe una tabla de muchos a muchos entre etiquetas y productos (luego el producto se sabe que categorías tiene haciendo un join a sus etiquetas).

En este caso vas a tener un problema y es la velocidad ya que para saber a que categorías pertenece un producto vas a necesitar saber todas sus etiquetas y prácticamente recorrer internamente todos los registros de la tabl, para esto vas a necesitar crear tablas desnormalizadas, esto quiere decir que vas a tener una tabla con tres columnas, id de producto, id de categoría y id de etiqueta, vas a tener duplicidad de datos pero serán accesibles de manera mucho mas rápida, y esta tabla no debe tener relaciones a excepción del id de producto, esto hará que para consultar productos por categoría no tengas que hacer joins y ahogar la memoria de la base de datos, pero también quiere decir que desde tu código web (php, java, .net, etc) en tu modelo de datos necesitarás hacer que cada ves que se modifique un producto o etiqueta también lo haga a esta tabla desnormalizada, de esta manera cada ves que insertes un registro se llenará tu tabla desnormalizada y harás que tus consultas a la base de datos sean extremadamente rápidas. Luego con el tiempo puedes aplicar técnicas de particionamiento de tablas.

¿No has pensado en utilizar magento que ya está construido y viene con muchas buenas prácticas?, si quieres tener tu propio sitio web de venta de cosas entonces no te recomiendo que hagas un sistema de cero, pero si quieres distribuir tu sistema vendiéndolo o cediéndolo, entonces está bien.

Saludos.