Hello, I am developing an application that will have 100''s of model classes each derived from a single source class. Each model will have 4 similar attributes but then have about a dozen unique ones each. I looked into using STI but balked at creating tables with a 1000 columns. I then looked at using inherits_from and creating an new table for each class that holds the new class columns. Problem is, I''ll end up with 100''s of tables, which also does not appeal to me. My third solution, the one I am asking advice on, is this. I create a single table with the 4 common columns and a dozen columns with names such as float1, float2, float3, ... , string1, string2, .. etc. Creating enough columns of each type to cover my largest subclass. Then I use STI and for each class I map the generic columns to the nicer names inside the subclasses. So in one class float1 may be miles/hour while in another class it might be turkeys/hectare. Does this sound like a reasonable approach? Also, how would I map the generic names to nice names in my subclasses? (I am a RoR noob) And of course, does anyone see a much better way to do what I have proposed? Thank you, Ryan Glover -- 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 -~----------~----~----~----~------~----~------~--~---
Ryan Glover wrote:> Hello, > > I am developing an application that will have 100''s of model classes > each derived from a single source class. Each model will have 4 similar > attributes but then have about a dozen unique ones each. I looked into > using STI but balked at creating tables with a 1000 columns. I then > looked at using inherits_from and creating an new table for each class > that holds the new class columns. Problem is, I''ll end up with 100''s of > tables, which also does not appeal to me. > > My third solution, the one I am asking advice on, is this. > > I create a single table with the 4 common columns and a dozen columns > with names such as float1, float2, float3, ... , string1, string2, .. > etc. Creating enough columns of each type to cover my largest subclass. > Then I use STI and for each class I map the generic columns to the nicer > names inside the subclasses. So in one class float1 may be miles/hour > while in another class it might be turkeys/hectare. > > Does this sound like a reasonable approach? > > Also, how would I map the generic names to nice names in my subclasses? > (I am a RoR noob) > > And of course, does anyone see a much better way to do what I have > proposed? > > Thank you, > Ryan Glover > > -- > Posted via http://www.ruby-forum.com/.My guess is that there is a much better way of approaching this. If you have hundreds of different attributes, there is probably a much simpler way of thinking about your data that will vastly simplify things in the long run. For example, if you have several different attributes denoting a value in ''mph'', ''ft/s'', ''m/s'', etc.. it would be better to store the value as a ''value'' attribute and a ''unit'' attribute. A clearer explanation of exactly what you are trying to accomplish would go a long way. _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?hl=en -~----------~----~----~----~------~----~------~--~---
Ryan Glover
2006-Dec-28 03:49 UTC
Re: Single Table Inheritance with a (possibly dumb) twist
Hello Kevin> My guess is that there is a much better way of approaching this. If > you have hundreds of different attributes, there is probably a much > simpler way of thinking about your data that will vastly simplify > things in the long run.The attributes in my models are wide and varied. They range from tangential firing type, to cars per hour, to tonnes of pig manure. If I was to create a column for each of them in the traditional manner I would have hundreds of unique columns. I believe that by creating generic float and string columns I can store this data in a compact manner. In my mind, the difference between this and a traditional STI is very minimal. In my case, I simply repurpose the fields for different things across sub classes. At the end of the day the type column will let me know what subclass I am working with.> For example, if you have several different attributes denoting a value > in ''mph'', ''ft/s'', ''m/s'', etc.. it would be better to store the value as > a ''value'' attribute and a ''unit'' attribute.This is essentially what I am doing except without the unit attribute, which I think is a grand idea. I could have a column named float1 and then a column named float1_unit. That would make looking at the data in the db more clear. Others I have spoken with have stressed the lack of purity in the db schema I have proposed and have insisted that I will end up hanging myself in the future because the db will be impenetrable without my special decoder classes. However, the purity of hundreds possibly thousands of tables with a few dozen rows each is not something I relish. Thanks for your response, Ryan Glover -- 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 -~----------~----~----~----~------~----~------~--~---
Ryan Glover wrote:> Hello Kevin > > > My guess is that there is a much better way of approaching this. If > > you have hundreds of different attributes, there is probably a much > > simpler way of thinking about your data that will vastly simplify > > things in the long run. > > The attributes in my models are wide and varied. They range from > tangential firing type, to cars per hour, to tonnes of pig manure. If I > was to create a column for each of them in the traditional manner I > would have hundreds of unique columns. I believe that by creating > generic float and string columns I can store this data in a compact > manner. > > In my mind, the difference between this and a traditional STI is very > minimal. In my case, I simply repurpose the fields for different things > across sub classes. At the end of the day the type column will let me > know what subclass I am working with. > > > For example, if you have several different attributes denoting a value > > in ''mph'', ''ft/s'', ''m/s'', etc.. it would be better to store the value as > > a ''value'' attribute and a ''unit'' attribute. > > This is essentially what I am doing except without the unit attribute, > which I think is a grand idea. I could have a column named float1 and > then a column named float1_unit. That would make looking at the data in > the db more clear. Others I have spoken with have stressed the lack of > purity in the db schema I have proposed and have insisted that I will > end up hanging myself in the future because the db will be impenetrable > without my special decoder classes. However, the purity of hundreds > possibly thousands of tables with a few dozen rows each is not something > I relish. > > Thanks for your response, > Ryan Glover > > > > -- > Posted via http://www.ruby-forum.com/.I suppose another way to handle it would be to use a one-to-many relationship. object has_many :attributes Where an attribute is defined as name : string => ''tons of manure'' attr_type : string => [''string'',''integer'',''float'', ''datetime''] attr_svalue :string => string representation of value attr_nvalue :float => numeric representation of value then set up a class for the attributes to handle the type conversions if necessary... this could be polymorphic aware. If you are interested in units, the ''ruby-units'' gem can be used to handle units in a rails app. You just save the unit value as a string, and cast it to a unit when you retrieve it and you can then do normal unit transformations and math with it. _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?hl=en -~----------~----~----~----~------~----~------~--~---