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 Sindhwani wrote:> 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?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 On 6/28/06, cremes.devlist@mac.com <cremes.devlist@mac.com> wrote:> > On Jun 28, 2006, at 4:23 AM, Mohit Sindhwani wrote: > > > 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? > > 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 > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- rm -rf / 2>/dev/null - http://null.in
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 > > -PratikHi 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.