The domain I'm trying to model is that of a web app (already fully developed in J2EE) with multiple customers. The web app has a large set of features, but any given customer only has a subset of those. Each feature also has a set of configurable parameters that alter it's behaviour. Each customer will have a different set of parameter values for their features.
The intention is to build a RoR in-house web app to track the J2EE web app and bring some sanity to our documentation and testing processes, which are currently being performed in an adhoc, chaotic manner that leaves critical information spread out in mutiple directories on multiple machines. I see RoR as the lasso that can reign in this disorder and keep the company from sinking under the weight of these inefficiencies.
The database tables seem clear enough, but I'm having difficulty moving away from relational database thinking to the ORM associations paradigm. Please forgive me if some of what follows is almost completely ignorant of the Rails Way. I'm learning RoR on the fly, as it were - this is a stealth project, and I need to get something impressive up and working fast, before lots of money (and momentum) get spent going in the WRONG direction.
Here are the tables I see as necessary (along with their minimal attributes):
CUSTOMERS id name
FEATURES id name description
CUSTOMERS_FEATURES customers_id features_id
PARAMETERS id features_id value_range
CUSTOMERS_PARAMETERS customers_id parameters_id value
My initial hack at this in Rails associations would be: FEATURES has_and_belongs_to_many CUSTOMERS CUSTOMERS has_and_belongs_to_many FEATURES (this implicitly defines CUSTOMERS_FEATURES, correct?) FEATURES has_many PARAMETERS PARAMETERS belongs_to FEATURES CUSTOMERS has_and_belongs_to_many PARAMETERS PARAMETERS has_and_belongs_to_many CUSTOMERS (implicitly defines CUSTOMERS_PARAMETERS?)
I won't be able to try this out until this evening, but is this even in the ballpark of the correct approach?
