Relation model naming advice needed

I have two models: Product and InvolvedParty

"Product" stores information about building materials and
"InvolvedParty" stores... well, involved parties, related to the
products. This could be a person who has administrative rights over
the products, the product manufacturer, a reseller, a contractor who
uses the products when building etc.

Between the two models I need a relation model (has_many :through) as
I of cause need to store information on the relation about which type
of relation we are dealing with. Remember, that in real life the same
involved party could be both a manufacturer and reseller but maybe of
different products.

To get to the point: What should I name this relation model?

According to Ryan Bates (http://railscasts.com/episodes/47) it's good
practice to name your relation model something meaningful instead of
just "involved_party_product" as the convention was with HABTM.

My problem here is that I'm very abstract. And the most abstract
relation name I can think of is "Relation", but I can't go calling all
my relation models that :wink:

Currently the only sensible name I can come up with is {HABTM}Relation
- I.e. InvolvedPartyProductRelation.

/thomas

Thanks for all the response - This is why I like the Rails community
so much :slight_smile:

I agree with changing the model name to Party, but frankensteining the
two names into ProductParty to name the join model is ugly. The fact
that you can't tell if it should be named ProductParty or PartyProduct
is evidence enough that it's a bad approach. A good, solid noun (or
gerund or participle) beats duct-taping two nouns together any day.

I would very much like to avoid calling it anything like PartyProduct
etc. since this is not very telling about it's content. "Involvement"
is not a bad idea... I was also thinking of "Ownership" but in that
case the meaning of "own" has to be taken lightly.

As for the name "InvolvedParty" instead of just the more simpler
"Party", I agree with you personally, but we are using a modeling
pattern that uses 9 different base models that in theory are so
abstract that they can hold everything (based on the Zachman
Framework: http://en.wikipedia.org/wiki/Zachman_framework). This
should make our app more future-prof. This modeling pattern uses
"InvolvedParty". Of cause we can call our models anything we like just
as long as we remember that this one relates to "InvolvedParty" in the
pattern specification - but it's just easier to use the original name.

Involvement sounds pretty good. I'll rant here on names of sets for a
second. I am somewhat of a student of Joe Celko, but I doubt that him
and I would get along at all over a cup of coffee or a pint of
bitter :slight_smile:

For the record...

A groups of users is not Users, it's Personnel.
A group of users that are part of several groups should not be in a
table called User_Group, but rather in a table called Membership.

Sorry. Had to get that off my chest. Use collective nouns where
possible. Follow up with plurals if necessary.

Todd

Toddwrote:
> For the record...

> A groups of users is not Users, it's Personnel.
> A group of users that are part of several groups should not be in a
> table called User_Group, but rather in a table called Membership.

> Sorry. Had to get that off my chest. Use collective nouns where
> possible. Follow up with plurals if necessary.

Except that "membership" begs the question of "in what?" and a group of
users could just as meaningfully be called "humans", or "colleagues", or
"students", or any number of other collective nouns that more or less
impart greater and lesser information regarding the nature of the group.
The word "personnel" implies a contractual relationship among the group
such as the employees of a firm or the crew of a ship, distinct from the
clients of a company or the passengers on a vessel. Is that actually
the intent here, that "outsiders" can never, ever access the system?
What about auditors? Law enforcement officers? Government tax
investigators? Are these all "personnel"? I doubt it.

Okay then. People. It obviously depends on the use case.

Further, in data modeling one must not only consider the problem domain
but the design architecture and its inherent limits when specifying
names of the implementation elements. The question of whether
product_parties or party_products is the correct name of a join table
hinges upon the dominant direction of consideration.

Which, could, in fact, change over time.

The fact that this
is not clear from the outset demonstrates that part of the problem
domain is insufficiently understood rather than reflect a basic flaw in
approach.

If products are the significant entity then product_parties makes sense.
If parties are the significant element then party_products makes sense.
If both parties and products are more or less equivalent from the point
of view of system usage, in other words one is as likely as the other to
be the point of reference for a user query, then simply sub-class one
from the other and use either as appropriate to the situation.

Frankenstiening words is a time honoured practice in languages having
germanic influences, such as English. Hand-Book (ger.) is far more
descriptive of the nature of an artifact than "Manual" (lat.) will ever
be. Just as product_parties is far more meaningful with respect to the
relationship of parties and products than involvements will ever convey.

What, pray tell, do you do with ternary relationships?

If a join relationship has independent significance, like a subscription
or a purchase order, then it can and should be appropriately named for
its own distinctive attributes. Otherwise simpler and clearer is better
from an implementation and maintenance point of view

Sorry. Don't buy it. Happy logistical names of tables do not a happy
programmer make (well, momentarily). This is a classic example of
people using names to discern function when really they should be
disjunct.

The point is that this sort of naming (table_on_table) makes clear to
the designers and programmers that party_products has dependencies on
two named tables whereas "involvement" conveys absolutely nothing
relating to the elements that are involved. If you prefer opening up
classes to get such basic information as to which database tables are
impacted then by all means "futurfy" your design as you see fit.
Myself, I see no good purpose served by obscufating logical connections
enforced by database design choices.

Hey, if a table named users_groups floats your boat, no big deal.
I'll work around it :slight_smile:

Todd

Todd wrote:
> What, pray tell, do you do with ternary relationships?

Reflection reveals that ternary relationships are nothing more than a
special case of the substantive join table and their names are therefore
usually quite obvious. One can consider the join of Products,
Locations, and Lots to come up with Stock or Inventory, or that of
Courses, Instructors, and Students to come up with Sections or Classes.
In these cases, as is usual with ternary joins, the result is almost
always a first order design element in itself.

> Sorry. Don't buy it. Happy logistical names of tables do not a happy
> programmer make (well, momentarily). This is a classic example of
> people using names to discern function when really they should be
> disjunct.

Whatever the word logistical is meant to convey in this paragraph
escapes me. I also do not understand the desire to name things with
such arbitrariness that they convey no meaning. One might as well have
table A, table B, table C and table D if a name is to have no congruency
with purpose and function.

Right. The next application I write will be named
"Crop_pictures_to_correct_size".

Names that imply direct function have little practical purpose. And,
besides that, just aren't sexy :slight_smile:

> Hey, if a table named users_groups floats your boat, no big deal.
> I'll work around it :slight_smile:

> Todd

Yet user groups are quite a common construct, both in the real world and
in systems design paradigms. I find it amusing that you evidently
depreciate the term to the extent that you feel it necessary to "work
around" it.

I find it amusing that you are so willing to "go with the flow".

Todd

That's what you're supposed to do when working with opinionated
software like Rails.