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?
Hola
Generar las tablas de forma dinámica es complicado y ademas te obliga a hacer cambios en programación cada dos por tres.
Un fallo en un campo, te dejaría fuera de combate la tienda al completo.
Yo iria a pensar mas bien en productos genéricos y no en que tipo de producto.
Podria los campos comunes numéricos y el titulo del producto en una tabla, que llamaríamos principal, los elementos comunes genéricos comunes de texto en otra tabla (para hacer mas ligera la tabla principal) y luego los accesorios, comunes pero poco consultados en una tercera. La breve descripción del producto luego ves en cual es mas interesante ponerla, de las dos primeras. Una cuarta tabla la dejaría para campos especiales que no son comunes a todos los tipos de producto.
Piensa que el panel de productos que se presenta a la entrada de la tienda solo debería consultar la primera y la segunda y debe ser común a todos los productos de la tienda. Lleva allí cualquier campo de uso común que sea necesario y piensa que si es necesario para presentar dicha pagina, debe estar allí, aunque solo se use en un tipo de producto.
Para plantearlo, piensa en el producto como un todo y no como un tipo de producto. El objeto producto debe ser capaz de englobar cualquier tipo de producto... Los tipos excepción también.
Puede publicar nuevos temas en este foro No puede responder a temas en este foro No puede editar sus mensajes en este foro No puede borrar sus mensajes en este foro No puede votar en encuestas en este foro No Puedes adjuntar archivos en este foro Tu puedes descargar archivos en este foro