Forum: Ruby on Rails Modelling: A table of domains

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Josh I. (Guest)
on 2006-06-12 23:07
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
Bryan D. (Guest)
on 2006-06-13 02:02
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.
Josh I. (Guest)
on 2006-06-13 12:28
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.
Bryan D. (Guest)
on 2006-06-14 01:27
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.
Josh I. (Guest)
on 2006-06-14 10:30
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.
This topic is locked and can not be replied to.