# Modelling: A table of domains **URL:** \ **Category:** Rails\ **Created:** [June 12, 2006, 9:07pm UTC](https://www.ruby-forum.com/t/modelling-a-table-of-domains/63160 "2006-06-12T21:07:23Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![joshibarra](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/94ad74/32.png) [@joshibarra](https://www.ruby-forum.com/u/joshibarra)\ **Post date:** [June 12, 2006, 9:07pm UTC](https://www.ruby-forum.com/t/modelling-a-table-of-domains/63160/1 "2006-06-12T21:07:23Z")
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 ---
**Author:** ![joshibarra](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/94ad74/32.png) [@joshibarra](https://www.ruby-forum.com/u/joshibarra)\ **Post date:** [June 13, 2006, 12:02am UTC](https://www.ruby-forum.com/t/modelling-a-table-of-domains/63160/2 "2006-06-13T00:02:47Z")
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. ---
**Author:** ![joshibarra](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/94ad74/32.png) [@joshibarra](https://www.ruby-forum.com/u/joshibarra)\ **Post date:** [June 13, 2006, 11:27pm UTC](https://www.ruby-forum.com/t/modelling-a-table-of-domains/63160/3 "2006-06-13T23:27:50Z")
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. ---
**Author:** ![joshibarra](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/94ad74/32.png) [@joshibarra](https://www.ruby-forum.com/u/joshibarra)\ **Post date:** [June 13, 2006, 10:28am UTC](https://www.ruby-forum.com/t/modelling-a-table-of-domains/63160/4 "2006-06-13T10:28:44Z")
Bryan D. 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. ---
**Author:** ![joshibarra](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/94ad74/32.png) [@joshibarra](https://www.ruby-forum.com/u/joshibarra)\ **Post date:** [June 14, 2006, 8:30am UTC](https://www.ruby-forum.com/t/modelling-a-table-of-domains/63160/5 "2006-06-14T08:30:49Z")
Bryan D. 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.