Greetings! I''m thinking of setting up a table of "domains", consisting of the core fields id, code, name, description, and type. Users is a domain, orders is a domain, recipes is a domain, etc. Domain attributes other than those covered by the core fields will go to, say, a user_other_fields table, recipe_other_fields, etc. I see the advantage of having all "things" in the database in one table. But there could be design disadvantages, and also Rails implementation disadvantages. Anyone has had experience in this area? Thank you for your thoughts. joshi -- Posted via http://www.ruby-forum.com/.
josh ibarra wrote:> Greetings! > I''m thinking of setting up a table of "domains", consisting of the core > fields id, code, name, description, and type. Users is a domain, orders > is a domain, recipes is a domain, etc. Domain attributes other than > those covered by the core fields will go to, say, a user_other_fields > table, recipe_other_fields, etc. I see the advantage of having all > "things" in the database in one table. But there could be design > disadvantages, and also Rails implementation disadvantages. Anyone has > had experience in this area? Thank you for your thoughts. > joshiWhat particular advantage does your app gain by this layout? Its going to be a pain both conceptually and practically. It''ll make your DB access more cumbersome and slower since you need to do 2 queries just to get a whole "something" record (ie user, recipe, whatever). Do you want to search the entire db at once? That''s not enough of an advantage to justify this complex arrangement. -- Posted via http://www.ruby-forum.com/.
Bryan Duxbury wrote:> josh ibarra wrote: >> Greetings! >> I''m thinking of setting up a table of "domains", consisting of the core >> fields id, code, name, description, and type. Users is a domain, orders >> is a domain, recipes is a domain, etc. Domain attributes other than >> those covered by the core fields will go to, say, a user_other_fields >> table, recipe_other_fields, etc. I see the advantage of having all >> "things" in the database in one table. But there could be design >> disadvantages, and also Rails implementation disadvantages. Anyone has >> had experience in this area? Thank you for your thoughts. >> joshi > > What particular advantage does your app gain by this layout? Its going > to be a pain both conceptually and practically. It''ll make your DB > access more cumbersome and slower since you need to do 2 queries just to > get a whole "something" record (ie user, recipe, whatever). Do you want > to search the entire db at once? That''s not enough of an advantage to > justify this complex arrangement.If I search for the word "store" in the Main table, I should get (at least) three entries: "store v" (as verb), "store n" (as noun) and "store a" (as adjective). Then if I choose "store n", I should get the stuff about store as noun from the Nouns table, or if I choose "store a", I should get the stuff about store as adjective from the Adjectives table. Every word entry is identified by the same set of core attributes -- id, code, name/token, which are abstracted away from the different parts of speech table, so they are not repeated for each parts of speech table. Just exploring this design. -- Posted via http://www.ruby-forum.com/.
josh ibarra wrote:> If I search for the word "store" in the Main table, I should get (at > least) three entries: "store v" (as verb), "store n" (as noun) and > "store a" (as adjective). Then if I choose "store n", I should get the > stuff about store as noun from the Nouns table, or if I choose "store > a", I should get the stuff about store as adjective from the Adjectives > table. Every word entry is identified by the same set of core attributes > -- id, code, name/token, which are abstracted away from the different > parts of speech table, so they are not repeated for each parts of speech > table. Just exploring this design.Are you writing a dictionary program? If so, I would just put every possible type of definition as a field on a Words model. Way less work to support. -- Posted via http://www.ruby-forum.com/.
Bryan Duxbury wrote:> josh ibarra wrote: > >> If I search for the word "store" in the Main table, I should get (at >> least) three entries: "store v" (as verb), "store n" (as noun) and >> "store a" (as adjective). Then if I choose "store n", I should get the >> stuff about store as noun from the Nouns table, or if I choose "store >> a", I should get the stuff about store as adjective from the Adjectives >> table. Every word entry is identified by the same set of core attributes >> -- id, code, name/token, which are abstracted away from the different >> parts of speech table, so they are not repeated for each parts of speech >> table. Just exploring this design. > > Are you writing a dictionary program? If so, I would just put every > possible type of definition as a field on a Words model. Way less work > to support.That''s the original/current approach. Thanks for the thoughts. -- Posted via http://www.ruby-forum.com/.