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.
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.