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
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 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.
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.
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.
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. 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.