Hello I have this scenario (hope it is understandable): I have a model to support fact messages of different types. This is sport related and I have currently the following model design. matchfacts (is the generic table connecting all matchfacts to for instance a match/game, match has_many matchfacts). Some matchfact-data is generic, like the time of fact and therefore the data should be stored there. Instead of making one table fits all, I want matchfacts to support certain predefined types. For instance: Goal, Substitution, Card and so on. What is best practice here? Use the polymorphic feature or create a model of each matchfact-type with a has_one connection to matchfacts model? The next problem is that each matchfact-type will probably also need either a enumeration or a matchfact-x-type model (where x is each matchfact-type (example of types can be: Red,Yellow card-types). This is to limit the different data beeing entered into model, but still make it dynamic and changeable by web-admin not database-admin. /MartOn --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
I just want to clearify a little more why this is not solved with one table. If we have a matchfact of type Goal. Goaltype must have one relation to player (the one who scored) If we have a matchfact of type Substitution, Substtype must have two relations to player (the one who got in and the one who got out). Having one matchfacts table would give me a table with many columns and only some of them used at once. /MartOn --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
MartOn wrote:> I just want to clearify a little more why this is not solved with one > table. > > If we have a matchfact of type Goal. Goaltype must have one relation to > player (the one who scored) > If we have a matchfact of type Substitution, Substtype must have two > relations to player (the one who got in and the one who got out). > > Having one matchfacts table would give me a table with many columns and > only some of them used at once. > > /MartOnYou might want to consider using single table inheritance (STI) for this. A true polymorphic system might be overkill. _Kevin --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hi MartOn, One rule of thumb I use is to decide if the application requirements for these items are more data-centric or behavioral in nature. If they are more data driven then I would tend to lump them in the same table but if behavioral then give them their own table. Having them in separate tables gives you way more flexibility and the opportunity to anchor them under a common superclass. This of course allows you to specify common behavior up in the superclass. Usually once you start down a certain path the best choice will make itself known. Paul Corcoran System Re-engineering, Inc. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---