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 ;)
Currently the only sensible name I can come up with is {HABTM}Relation
- I.e. InvolvedPartyProductRelation.
/thomas
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
Thomas Watson 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 Susser http://blog.hasmanythrough.com -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thomas Watson 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?dIf 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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
James Byrne 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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
James Byrne 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 Susser http://blog.hasmanythrough.com -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks for all the response - This is why I like the Rails community so much :) On Dec 2, 7:41 pm, Josh Susser <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> 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: 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Dec 2, 5:17 pm, Thomas Watson <w...-P0pGGzhPWaA@public.gmane.org> wrote:> Thanks for all the response - This is why I like the Rails community > so much :) > > On Dec 2, 7:41 pm, Josh Susser <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> > 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: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 :) 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> > 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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Dec 3, 9:18 am, James Byrne <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> 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 viewSorry. 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 :) > > ToddYet 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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Dec 3, 9:15 pm, James Byrne <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> 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 :)> > 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Dec 4, 2007 5:38 AM, Todd <caduceass-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 Donald http://destiney.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---