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