Hello, I need some direction for a project I''m working on. I''ve got a serious case of coders block :) So I have a model called Review which belongs_to Form. The Review has many (hundreds) attributes which differ depending on what type of Form it is. The attributes that they share would be in the reviews table, but I was thinking that there could be a sub table for each type of form, just to keep things seperated. I was also thinking each Review could be subclassed for each type of Form. Any input will be appreciated. Thanks! Aaron -- 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 -~----------~----~----~----~------~----~------~--~---
I have a similar problem:
I''m creating a site which will have several clients, each of which
will have items in our catalog. The app will be customized as far as
layout for each client, but the data for the items needs to be in (at
least)three different formats as well, one of which is that the data
will be in the form of a scanned image.
For the different attributes, I was thinking of making an item_data
table like so
id int ...
item id int
name varchar(45)
contents varchar or text
And then building my layout on that i.e.
<% for datum in @data %>
<tr>
<td><%= datum.name %></td>
<td><%= datum.contents %></td>
</tr>
<% end %>
I don''t know if this will work well, and I''m wondering if
there is a
better way to solve dynamic attributes for an object.
Jason
Aaron Wieberg wrote:> Hello, I need some direction for a project I''m working on.
I''ve got a
> serious case of coders block :)
>
> So I have a model called Review which belongs_to Form. The Review has
> many (hundreds) attributes which differ depending on what type of Form
> it is. The attributes that they share would be in the reviews table,
> but I was thinking that there could be a sub table for each type of
> form, just to keep things seperated.
>
> I was also thinking each Review could be subclassed for each type of
> Form.
>
> Any input will be appreciated. Thanks!
>
> Aaron
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Jason Norris wrote:> I have a similar problem: > I''m creating a site which will have several clients, each of which > will have items in our catalog. The app will be customized as far as > layout for each client, but the data for the items needs to be in (at > least)three different formats as well, one of which is that the data > will be in the form of a scanned image. > > For the different attributes, I was thinking of making an item_data > table like so > > id int ... > item id int > name varchar(45) > contents varchar or text > > And then building my layout on that i.e. > > <% for datum in @data %> > <tr> > <td><%= datum.name %></td> > <td><%= datum.contents %></td> > </tr> > <% end %> > > I don''t know if this will work well, and I''m wondering if there is a > better way to solve dynamic attributes for an object. > > JasonI think what you are talking about is like the Entity-Attribute-Value Design. See this site: http://ycmi.med.yale.edu/nadkarni/Introduction%20to%20EAV%20systems.htm I actually came up with a simple version of that that worked in Rails, but scrapped the idea because of all the reasons there are NOT to use it. (See http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:10678084117056 for some reasons). I''d be willing to share the code if you wanted to see it. I was thinking that maybe we don''t need the flexibility to the degree that design would provide, since it''s really not that much work to add a column in the database, or create a new table for a new Form type. I''m just sure someone has done this before so I don''t want to re-invent the wheel or anything. Aaron -- 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 -~----------~----~----~----~------~----~------~--~---
Aaron Wieberg wrote:> Hello, I need some direction for a project I''m working on. I''ve got a > serious case of coders block :) > > So I have a model called Review which belongs_to Form. The Review has > many (hundreds) attributes which differ depending on what type of Form > it is. The attributes that they share would be in the reviews table, > but I was thinking that there could be a sub table for each type of > form, just to keep things seperated. > > I was also thinking each Review could be subclassed for each type of > Form. > > Any input will be appreciated. Thanks! > > AaronI think this page may have the info you''re looking for: http://wiki.rubyonrails.org/rails/pages/SingleTableInheritance. Your current thinking seems to fall under Class Table Inheritance, but currently Rails only supports Single Table inheritance where you put ALL the attributes of the different type of Reviews into one single table, and use a type column to differentiate the review type. Personally, I think Class Table Inheritance seems to be most sensible of the different inheritance hierarchies, but if you want to use what''s already built into Rails, then Single Table Inheritance is the obvious choice. I read some article, I forgot the link, where someone did hack Rails to support Class Table Inheritance - hopefully someone else will be able to supply it. Nelson -- 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 -~----------~----~----~----~------~----~------~--~---
> I think this page may have the info you''re looking for: > http://wiki.rubyonrails.org/rails/pages/SingleTableInheritance. Your > current thinking seems to fall under Class Table Inheritance, but > currently Rails only supports Single Table inheritance where you put ALL > the attributes of the different type of Reviews into one single table, > and use a type column to differentiate the review type. Personally, I > think Class Table Inheritance seems to be most sensible of the different > inheritance hierarchies, but if you want to use what''s already built > into Rails, then Single Table Inheritance is the obvious choice. > > I read some article, I forgot the link, where someone did hack Rails to > support Class Table Inheritance - hopefully someone else will be able to > supply it. > > NelsonIs this the article you''re referring to? http://johnwilger.com/articles/2005/09/29/class-table-inheritance-in-rails-with-postgresql That sounds like a good start. I think that what he did using Postgre could be translated to Oracle. So I might just be able to use that. Thanks for the help! Part of the problem was I wasn''t even sure what to search for. Aaron -- 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 -~----------~----~----~----~------~----~------~--~---
Whew, you''re right, the implementation does look ugly for an EAV model. Thank you for the information, I''m glad I didn''t go ahead with developing that model. Using a single table where some or many values may be null in certain cases will certainly be easier, and I hadn''t really thought about how much performance would degrade using a "generic" model. Jason Aaron Wieberg wrote:> Jason Norris wrote: > >> I have a similar problem: >> I''m creating a site which will have several clients, each of which >> will have items in our catalog. The app will be customized as far as >> layout for each client, but the data for the items needs to be in (at >> least)three different formats as well, one of which is that the data >> will be in the form of a scanned image. >> >> For the different attributes, I was thinking of making an item_data >> table like so >> >> id int ... >> item id int >> name varchar(45) >> contents varchar or text >> >> And then building my layout on that i.e. >> >> <% for datum in @data %> >> <tr> >> <td><%= datum.name %></td> >> <td><%= datum.contents %></td> >> </tr> >> <% end %> >> >> I don''t know if this will work well, and I''m wondering if there is a >> better way to solve dynamic attributes for an object. >> >> Jason >> > > I think what you are talking about is like the Entity-Attribute-Value > Design. See this site: > http://ycmi.med.yale.edu/nadkarni/Introduction%20to%20EAV%20systems.htm > > I actually came up with a simple version of that that worked in Rails, > but scrapped the idea because of all the reasons there are NOT to use > it. (See > http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:10678084117056 > for some reasons). I''d be willing to share the code if you wanted to > see it. > > I was thinking that maybe we don''t need the flexibility to the degree > that design would provide, since it''s really not that much work to add a > column in the database, or create a new table for a new Form type. I''m > just sure someone has done this before so I don''t want to re-invent the > wheel or anything. > > Aaron > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---