2009-04-02 14 views
8

Estoy construyendo una tienda en línea para vender productos como "Camisetas extragrandes verdes". Es decir, la misma camisa puede tener muchos tamaños/colores, una combinación diferente puede agotarse, una combinación diferente puede tener precios diferentes, etc.Cómo modelar "productos" en una aplicación de tienda en línea

Mi pregunta es cómo debo modelar estos productos en mi aplicación Rails (o cómo hacerlo realmente hazlo en cualquier aplicación).

Mi pensamiento actual es:

Class Product 
    has_many :variants, :through => :characteristics 
    has_many :characteristics 
end 

Class Characteristic 
    belongs_to :product 
    belongs_to :variants 
end 

Class Variant 
    has_many :products, :through => :characteristics 
    belongs_to :characteristic 
end 

Así que cada producto tendrá una o más características (por ejemplo, "Color", "Tamaño", etc), y cada característica a continuación, tendrán una o más variantes (por ejemplo, "Rojo", "Azul", etc.).

El problema con este método es ¿dónde guardo el precio y el inventario? Es decir, el precio y el inventario de un determinado producto están determinados por las variantes que adoptan sus características. (El verde puede ser más caro que el rojo, grande puede estar agotado, etc.).

Una idea que tuve fue dar a los productos un "precio base", y dejar que las variantes lo modifiquen, pero esto parece demasiado complejo (y podría no funcionar).

Respuesta

13

He visto dos soluciones para este tipo de dilema. El primero es tratar de usar características para definir productos subordinados al producto "principal". El desafío aquí es que, además de sus pensamientos, en la mayoría de los casos, el producto evolucionará con nuevos fabricantes que traerán nuevos aspectos a la mesa. Por ejemplo, un fabricante puede hacer un producto más barato, pero tiene un método de aplicación diferente para el logotipo o costura que puede ser lo suficientemente importante como para rastrear.

Creo que llevar un número de producto no significativo para cada producto y luego asociar las características como atributos funciona mejor. Es fácil de buscar y extensible. Si un grupo de productos está fuertemente relacionado, un ProductGroup que los productos individuales anexen funciona bien.

En las tablas:

  ProductGroup 
      -------------------- 
      ProductGroupID 
      ProductGroupName 
      ProductGroupDescription 

      Product 
      -------------------- 
      ProductID 
      ProductGroupID 
      QtyOnHand 
      BasePrice 
      ProductColorID 
      ProductSizeID 

      ProductColor 
      ------------ 
      ProductColorID 
      ProductColorName 

      ProductSize 
      -------------- 
      ProductSizeID 
      ProductSizeName 

      ...more attributes... 

Las ventajas aquí son que se puede consultar fácilmente los atributos específicos, atributos son "flexibles" en la que se pueden añadir más (y los viejos ajustados: si usted empieza con "Rojo "pero luego agregó otro" Rojo "al grupo de colores, puede cambiarlos a" Marrón "y" Rojo brillante ".

Puede controlar el precio y el inventario en el nivel detallado del producto (aunque es posible que se necesiten más tablas) para dar cuenta de sourcing costos).

Todo esto supone que sus características se comparten universalmente. Si no lo son, su enfoque de subtabla característica puede funcionar al crear una tabla de combinación entre las características y las tablas de detalles del producto y poblar según sea necesario. Esto requerirá más lógica empresarial. Para garantizar que cada categoría de producto obtenga , todas las características de son necesarias. En este último caso usaría productos "prototipo" en la tabla de productos base (con Cant. Y Costo de 0) de los que clonaría las características y luego las ajustaría a medida que se ingresa cada nuevo producto. A medida que avanza, cuando aparece una nueva variación, tener una función "clonar este producto" que le permite ajustar las diferencias del producto base sería valioso.

Finalmente, en lo que respecta a la gestión del inventario y los precios, esto sucederá en la capa de la interfaz de usuario. Ser capaz de generar consultas para productos relacionados (grupos de productos) y administrar todos los precios de los productos relacionados contribuirá en gran medida a que esto sea habitable.

+0

Este es un buen consejo. En la empresa para la que trabajo tenemos solo dos tablas: Product y ProductItem, y el color y el tamaño no se normalizaron correctamente. Hace que administrar/asociar imágenes específicas de color sea una pesadilla absoluta. Así es como lo haría; el color y el tamaño son conceptos de primera clase ... –

+0

... y nos encontramos con escenarios donde "los amarillos se hacen en Tailandia pero los blancos son de China", pero como los almacenamos en el nivel de Producto, podemos No lo modela y termina duplicando el SKU, lo que causa otros problemas. Ser flexible pero proporcionar UI para los escenarios comunes es un consejo de +1. –

+1

Gracias Nicholas. Este consejo proviene de ser quemado con demasiada frecuencia al asumir que las características "fáciles" pueden ser simplemente rellenas en la mesa principal. Puedo ver fácilmente que la tabla "Color" finalmente gana más atributos debido a las diferencias de origen. Engraname una vez ... – Godeke

2

Solo una nota rápida. Siempre puedes probar y echarle un vistazo al código fuente de algunos otros productos de comercio electrónico como Spree y Substruct, probablemente ya hayan respondido esa pregunta por ti.

Cuestiones relacionadas