Relation model naming advice needed

[wet]

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 B. (#47 Two Many-to-Many - RailsCasts) 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

Currently the only sensible name I can come up with is {HABTM}Relation

• I.e. InvolvedPartyProductRelation.

/thomas

[wet]

Thomas W. wrote:

I have two models: Product and InvolvedParty
…
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?
…
Currently the only sensible name I can come up with is {HABTM}Relation

• I.e. InvolvedPartyProductRelation.

How about Involvement? I tend to go with -ing, -tion, and -ment nouns
for join model names. It doesn’t have to be a word you’d use in
conversation, as long as it makes sense when you are looking at your
code.

–
Josh S.
http://blog.hasmanythrough.com

[wet]

Thomas W. wrote:

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.

I think that you will find that it might be clearer to call these models
Product and Party. A party is, by definition, one who takes part in a
transacton, howerver peripherally. Non-involved entities are not
“parties”.

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

If you change the model names as suggested above then the join model
conventionally should be called party_products, but it could just as
well be called product_parties and that might be more meaningful.

[wet]

James B. wrote:

If you change the model names as suggested above then the join model
conventionally should be called party_products, but it could just as
well be called product_parties and that might be more meaningful.

I should write party_product and product_party instead.

[wet]

James B. wrote:

I think that you will find that it might be clearer to call these models
Product and Party. A party is, by definition, one who takes part in a
transacton, howerver peripherally. Non-involved entities are not
“parties”.
…
If you change the model names as suggested above then the join model
conventionally should be called party_products, but it could just as
well be called product_parties and that might be more meaningful.

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.

–
Josh S.
http://blog.hasmanythrough.com

[wet]

On Dec 2, 5:17 pm, Thomas W. [email protected] wrote:

gerund or participle) beats duct-taping two nouns together any day.
Framework:Zachman Framework - Wikipedia). 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

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

[wet]

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

On Dec 2, 7:41 pm, Josh S. [email protected]
wrote:

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: Zachman Framework - Wikipedia). 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.

[wet]

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.

well, ya. if the join table is going to ACTUALLY do something, like it
is a MEMBERSHIP, and it may have something like money associated to the
join table, then you don’t have to worry about what to call it. it
names itself. if the join table is just to basically, join, then the
table name x_x does make it easy to figure out, verses trying to figure
out what your the table name meant to you.

[wet]

Todd wrote:

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.

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

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.

[wet]

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.

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

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.

[wet]

On Dec 3, 9:18 am, James B. [email protected]
wrote:

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.

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

Todd

[wet]

On Dec 4, 2007 5:38 AM, Todd [email protected] wrote:

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

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

–
Greg D.
http://destiney.com/

[wet]

On Dec 3, 9:15 pm, James B. [email protected]
wrote:

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

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

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