Best way to structure this?

I’m thinking of an application in which a user can request for different
items (like office stationery). So, I have a table of users and a table
of requests. The thing is that depending on the item requested, the
parameters are different - for example, pens may have {colour, width,
type} while paper may have parameters such as {colour, size (A4,
letter, legal), stack size, quality}…

I’m thinking that I shall need to have one table per item (pens, paper,
etc.). The table will store the Request ID (from the requests table)
and also the details of the request. The problem I envisage is that
maintenance will require creating a new table every time a new type of
item is got.

Would this be the best way to manage this problem? Is there a different
approach that I should explore? How would I get my code to
automatically recognize the newly added items?

Thanks,
Mohit.

On Jun 28, 2006, at 4:23 AM, Mohit S. wrote:

envisage is that maintenance will require creating a new table
every time a new type of item is got.
Would this be the best way to manage this problem? Is there a
different approach that I should explore? How would I get my code
to automatically recognize the newly added items?

I don’t have a complete solution to your problem, but a few thoughts
do jump out.

One, I don’t understand the need for a requests table. I certainly
see the need for a Request model, but why store this information in
the database at all? It’s kind of analogous to a shopping cart. Take
a look at the Depot example in the AgileWDwR book.

Two, using polymorphic tables will allow you to make some of your
accessors generic. Every element offered from the “store” shares at
least a few attributes.

Three, instead of going down the path of polymorphic models, just
decide on a set of common characteristics and hammer all of your
items to fit in those slots. I don’t know if you are really building
an “inventory” style application or if this is just an example of
what you want to accomplish. If this is a real example, mimic what
every store on the net has done. They define a category, type, item
hierarchy while each element contains an id, name, quantity, price,
description, etc.

I hope something in here was helpful.

cr

I think the following should work :

users - has_many:requests
requests - has_many :details
items - has_many :attributes
attributes - belongs_to :item ( store names of attributes like colors,
length, etc. for each item )
details - value, belongs_to :attribute, :request

-Pratik

Pratik wrote:

I think the following should work :

users - has_many:requests
requests - has_many :details
items - has_many :attributes
attributes - belongs_to :item ( store names of attributes like colors,
length, etc. for each item )
details - value, belongs_to :attribute, :request

-Pratik
Hi Pratik & CR,

Thanks for the replies… I am actually working through the Agile
Development book right now (page 99 of 637) and will be exploring these
issues as I go along. While going through it, I’m thinking also of
ideas that I’d like to implement - that’s why I asked!

Pratik - I’m a bit confused with the above answer (sorry, still
learning!) If I understand correctly, the attributes would store the
“names” of the attributes and the actual attribute would be stored in
the “details”? So, “details” would essentially be a “value” that is
linked to a specific “attribute” for a specific “request”?

Thanks again,
Mohit.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs