Carriles para múltiples tipos de productos carrito de la compra

Question

Im diseñar una aplicación que gestiona el alquiler de muchos equipos diferentes. Y me pregunto cuál es la mejor manera de diseñar los modelos para la aplicación. Mi software tiene que manejar una gran cantidad de diferentes tipos de equipos (con tipos de datos), por ejemplo:

Speaker 
    Make - String 
    Model - String  
    Wattage - Integer 
    Price - Decimal 

Light 
    Make - String 
    Model - String  
    Wattage - Integer 
    Price - Decimal 

Microphone 
    Make - String 
    Model - String 
    Use - Choice of: Instrumental, Vocal, Versatile 
    Price - Decimal 

Cable 
    Length - Decimal 
    Connector 1 - String 
    Connector 2 - String 
    Price - Decimal 

Stand 
    Type - Choice of: Microphone, Speaker 
    Height - Decimal 
    Boom - Boolean 
    Price - Decimal 

maneras he pensado en el diseño:

• un modelo individual para cada tipo de producto, entonces una asociación polimórfica en el carro para que pueda manejar todo tipo de equipos.
• Un modelo de producto único que tiene campos para todo tipo de equipos con un campo de tipo que se puede comprobar siempre que se utilice el producto.
• Un modelo de producto con un atributo de precio y cada tipo de producto amplía ese modelo.

Pero, ¿cuál es la mejor manera en los rieles para manejar estos diferentes tipos de productos?

Answer 1

El atributos dinámicos gema debe permitirle hacer esto de forma automática:

https://github.com/moiristo/dynamic_attributes

Puede haber mejores joyas que hacer lo que tiene, pero esta es la primera vez que he encontrado.

Si está utilizando Postgres como su base de datos, puede usar hstore. Hay gemas para trabajar con hstore. Si puede pagar, obtenga una suscripción a Railscast y mire el screencast sobre la implementación de hstore.

Activerecord-postgres-hstore parece ser la joya para esto.

Answer 2

Otra opción sería crear una tabla de atributos del producto y construir cada tipo de producto a través de una interfaz de administración en lugar de en un código de bajo nivel. De esta forma, no necesitaría modificar la aplicación para vender nuevos productos.

Answer 3

El tercer enfoque es bastante cercano al correcto. Definitivamente, deseará abstraer todos los parámetros universales para los elementos (como el ID de la tienda y, como usted mencionó, el precio) en el modelo base que extenderá cada otro artículo. Luego, como mencionó en su primera solución propuesta, tendrá referencias entre el resto de las clases de elementos cuando sea necesario, utilizando: referencias.

En cuanto al "tipo" y "uso", probablemente será mejor que utilice una relación de uno a uno con el modelo principal. Luego, almacene una lista de posibles tipos de campo para cada uno de los modelos (por ejemplo, para Stand, algo así como possible_uses = "Microphone, Speaker"). Finalmente, haga la validación del lado del servidor cuando se crea una instancia del modelo que asegure que sea de un tipo válido. También puede hacer algunos hacks que le permitirán ver asegurarse de que Microphone y Speaker son los dos únicos "usos" posibles que su código realmente utiliza.

Una manera completamente diferente, pero más limpia de hacer esto sería hacer todo lo que mencioné en el primer párrafo, pero continuar la herencia hasta los niveles inferiores. Específicamente, tienen Microphone extender BaseItem, dar Microphone los parámetros Make y Model, y luego tener modelos InstrumentalMicrophone, VocalMicrophone, and clase VersatileMicrophone extend the Microphone`. Este será el más limpio y permitirá una funcionalidad completa.

Answer 4

Yo personalmente iría con un único modelo de producto y otro modelo llamado ProductAttribute.

En esta tabla, tendría una columna name y una columna value.

De esta manera, no está limitado por su esquema. Un producto tiene n product_attributes, nombrado dinámicamente. En la sección de administración puede desarrollar accesos directos, de modo que si crea un producto de micrófono, creará automáticamente los nombres de los atributos específicos en la tabla vinculada. Solo tendrías que ingresar los valores.

De esta forma, su aplicación puede vender cualquier tipo de producto con cualquier cantidad de atributos.No es necesario volver a codificar cuando en 3 meses el administrador querrá agregar otro tipo de producto :)

Editar: Y por supuesto, usted tendría un modelo ProductType para administrar los diferentes tipos de productos que puede vender.

Answer 5

Este es un problema que ha causado dolores de cabeza a muchos proveedores de soluciones ERP antes. La solución más elegante que te sugiero en base a lo que he visto en uno de esos proveedores es esta.

Defina 4 modelos: Equipo, Tipo de equipo, Característica, Elección.

Habría una relación de muchos a muchos entre Equipo y Característica, pasando por EquipmentType. El modelo de característica tiene un atributo llamado "value_type" y también un atributo para cada tipo de valor que tiene (String, Integer, Decimal, Boolean). Finalmente, habría una relación uno a muchos entre Characteristic y Choice.

Esta es en realidad una versión diluida de la implementación de ese proveedor que se adapta a sus necesidades particulares. La implementación real de ese proveedor en realidad está construida en uno o dos niveles de abstracción por encima de lo que le muestro, para hacer que la solución sea más genérica. Pero esas personas son bien conocidas por su exceso de ingeniería.

HTH.