is that a good example for using has_many :through?

I have Company has_many :categories and Category has_many :companies.
One Company for an associated Category has classifications, example:
Company-1 has Category OG1 with Classification_type I
Classification_amount 10.000 and Classification_type II
Classification_amount 50.000.
Is that a good reason to use Company has_many categories through
categorizations in which put attributes for Classifications?

I'm not sure, because I don't see the connection between
Classification and Category. If a Company's Classifications only make
sense within the context of a given Category, then yes, HMT *might*
make sense. You'd have to give us more information.

Another question is whether the Classifications are few and fixed,
e.g., there are only those two (or maybe a few more), and there is
very little chance of any more being added. If so, then it *might*
make sense to make those attributes of the company-classifications
relation. Otherwise I'd be tempted to make them their own class, and
either refer to the company-classification, or refer directly to the
Company and Classification.

Let's take a more fully fleshed-out example, from an app I'm designing
at the moment. In Toastmasters, Clubs have many Members, and a Member
can have many Clubs. So far, this could be done with either HMT or
HABTM. But, there is information about a Member, that only makes
sense in the context of a given Club, such as when he joined, and when
his dues expire. That points to creation of a Membership table, with
foreign keys into the Member and Club tables. Each will have_many of
the other, :through => :Memberships.

But then there are other possible relationships. Each Club can have
several officers, some of which are standard (President, Vice
President of Education, etc.), and some of which are not (Webmaster,
Corporate Liaison, etc.). The standard ones *could* be done as
attributes of a Club, holding the ID of the appropriate Member. But
the nonstandard ones should be separate. (One could say "give them a
number of slots, each with a name and a Member ID, but that approach
has been tried in similar circumstances and found too limiting.)
Alternately one could put an office_name or even office_list on the
Membership record, but that's also rather inflexible (given that
Members may hold multiple Offices in one Club) and wasteful (given
that most Members won't be Officers at any given time). So, I've
planned this out as an Office record, having a name, the ID of the
Club, and the ID of the Member. Given that we have those, and given
that I'd like this thing to be usable for other than Toastmasters
clubs, I intend to use that sort of schema for *all* the offices.
It's still a bit fragile, given that the Office names could get
translated or misspelled, but I think it's a reasonable compromise, as
I don't want to maintain a master list of Office names.

Is any of this analogous to what you're trying to do? Does it at
least shed some light on when you might want to tack things onto a
relationship table?

-Dave

I have Company has_many :categories and Category has_many :companies.
One Company for an associated Category has classifications, example:
Company-1 has Category OG1 with Classification_type I
Classification_amount 10.000 and Classification_type II
Classification_amount 50.000.
Is that a good reason to use Company has_many categories through
categorizations in which put attributes for Classifications?

I'm not sure, because I don't see the connection between
Classification and Category. If a Company's Classifications only make
sense within the context of a given Category, then yes, HMT *might*
make sense. You'd have to give us more information.

Yes it is.
A Company has one or more categories associated and for each of the
associated category has one type of classification.

Another question is whether the Classifications are few and fixed,
e.g., there are only those two (or maybe a few more), and there is
very little chance of any more being added. If so, then it *might*
make sense to make those attributes of the company-classifications
relation. Otherwise I'd be tempted to make them their own class, and
either refer to the company-classification, or refer directly to the
Company and Classification.

Classifications are about 10 and there is a chance of being added more
or being modified.
Classification attributes are "classification_type" and "amount".