# Just a matter of taste or the need of a formal approach? **URL:** \ **Category:** Rails\ **Created:** [July 13, 2009, 2:19pm UTC](https://www.ruby-forum.com/t/just-a-matter-of-taste-or-the-need-of-a-formal-approach/172022 "2009-07-13T14:19:42Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![msmsms](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/34f0e0/32.png) [@msmsms](https://www.ruby-forum.com/u/msmsms)\ **Post date:** [July 13, 2009, 2:19pm UTC](https://www.ruby-forum.com/t/just-a-matter-of-taste-or-the-need-of-a-formal-approach/172022/1 "2009-07-13T14:19:42Z")
Hi, thanks for reading this post. At the moment, I am thinking about the following problem: Let’s assume the following situation: I’ve got two entity types called “User” and “Group”. Each entity type got some attributes, let’s think about “name” and “password” for “User” and “name” as well as “type” for “Group”. Those attributes are not really essential for my problem description. So now we have: User - name - password Group - name - type We can also create relations between those entities, for example: membership(Gx, Uy), which tells us that user y is a member of group x. As all users can join multiple groups, we could just create an intermediate join table to model this for our relational database, so far, that’s all right, there are no other reasonable solutions, as far as I know. Now, let’s assume you could dynamically add an arbitrary number of attributes, which can of course also be just foreign keys, to each entity and that this is also supported by your database system. This is the case, I am dealing with and it brings in some new thoughts about modeling the relation between “User” and “Group”. If we look at the relation “membership” again, you could also think: Well, somehow, “member” could be an attribute of “Group”, so we would say: Group - name - type - member\_fk\_1 (or user\_fk, that’s not essential here) - member\_fk\_2 (also the naming is not essential) … And you could say, well: the fact, that a user is a member of a group, could also be represented by further “User” attributes: User - name - password - group\_fk\_1 (the naming again is not essential here) - group\_fk\_2 … The fact, that you can add as many fields as you want, makes both solutions possible. In fact, only one entity should save the membership information, as we are following the dry principle. What to do now? How would you argue? Should I use a join model anyhow or should I really decide to model the membership in the second way? Maybe: Is there a formal approach to decide this? There are other examples, where I have got to model some kind of composition: in this case I have got entities which are components of other entities, which only can exist through out these associations. In this case, it is somehow more intuitive to model the foreign keys directly as attributes not using a join model. Thanks for you suggestions! Cheers, ms ---
**Author:** ![msmsms](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/34f0e0/32.png) [@msmsms](https://www.ruby-forum.com/u/msmsms)\ **Post date:** [July 13, 2009, 2:55pm UTC](https://www.ruby-forum.com/t/just-a-matter-of-taste-or-the-need-of-a-formal-approach/172022/2 "2009-07-13T14:55:43Z")
Investigate polymorphic join relationships… you can join arbitrary numbers of other ‘things’ without adding foreign\_keys to your base table (User). A new ‘thing’ just has to participate in the poly join relationship. Requirement (these can be related to any number of other entities, depending on how that project team manages their data) has\_many :reqlinks, :dependent =\> :destroy has\_many :unittests, :through =\> :reqlinks, :source =\> :unittest, :conditions =\> “reqlinks.reqlinkable\_type = ‘unittest’” has\_many :scenarios, :through =\> :reqlinks, :source =\> :scenario, :conditions =\> “reqlinks.reqlinkable\_type = ‘scenario’” has\_many :projects, :through =\> :reqlinks, :source =\> :project, :conditions =\> “reqlinks.reqlinkable\_type = ‘project’” Reqlink (the polymorphic join table) belongs\_to :requirement belongs\_to :reqlinkable, :polymorphic =\> true belongs\_to :unittest, :class\_name =\> ‘Unittest’, :foreign\_key =\> ‘reqlinkable\_id’ belongs\_to :scenario, :class\_name =\> ‘Scenario’, :foreign\_key =\> ‘reqlinkable\_id’ belongs\_to :project, :class\_name =\> ‘Project’, :foreign\_key =\> ‘reqlinkable\_id’ Project has\_many :reqlinks, :as =\> :reqlinkable, :dependent =\> :destroy has\_many :requirements, :through =\> :reqlinks Scenario has\_many :reqlinks, :as =\> :reqlinkable, :dependent =\> :destroy has\_many :requirements, :through =\> :reqlinks Unittest has\_many :reqlinks, :as =\> :reqlinkable, :dependent =\> :destroy has\_many :requirements, :through =\> :reqlinks ---
**Author:** ![msmsms](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/34f0e0/32.png) [@msmsms](https://www.ruby-forum.com/u/msmsms)\ **Post date:** [July 13, 2009, 5:53pm UTC](https://www.ruby-forum.com/t/just-a-matter-of-taste-or-the-need-of-a-formal-approach/172022/3 "2009-07-13T17:53:55Z")
ms wrote: […] > What to do now? How would you argue? Should I use a join model anyhow > or should I really decide to model the membership in the second way? You should use a junction table and habtm or has\_many :through. Repeating fields may seem more intuitively appealing, but they are a terrible DB design technique. Please read some articles on DB normalization (the ones on Wikipedia are excellent), and feel free to ask if you have any further questions. Generally speaking, most applications should have their tables at least in Third Normal Form (3NF). > Maybe: Is there a formal approach to decide this? Yes. Never use repeating fields. 🙂 > There are other examples, where I have got to model some kind of > composition: in this case I have got entities which are components of > other entities, which only can exist through out these associations. Can you post an example? > In this case, it is somehow more intuitive to model the foreign keys > directly as attributes not using a join model. But the intuitive solution is not _always_ the best (although it’s often a good place to start). > Thanks for you suggestions! > > Cheers, > ms ## Best, Marnen Laibow-Koser [http://www.marnen.org](http://www.marnen.org) removed\_email\_address@domain.invalid