Need some direction re: model setup

Hello, I need some direction for a project I’m working on. I’ve got a
serious case of coders block :slight_smile:

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

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 %>


<%= datum.name %>
<%= datum.contents %>

<% 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

Jason N. 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 %>

<%= datum.name %>
<%= datum.contents %>

<% 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:

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

Aaron W. wrote:

Hello, I need some direction for a project I’m working on. I’ve got a
serious case of coders block :slight_smile:

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

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.

Nelson

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

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.

Nelson

Is 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