This is currentlymaking my head spin, and it looks like i cant get a
clear answer: so im turning to you.
In my sandbox application i have users and these have profiles: in
profiles i store information like a “about me” and country, state and
city. And some other information (all who the user select from a
select box).
In my current design i have:
user => has_one :profile
and then:
profile => has_one :country
=> has_one :state
=> has_one :city
=> has_one etc etc etc
Is this the bes way to design an application or should i store data as
a string instead (like Country => String Sweden) etc ?
How would you do this ?
On Jun 6, 2011, at 10:45 AM, Niklas N. wrote:
How would you do this ?
It depends. If you want to have convenience methods in your code,
where there is a picking list of countries, for example, to cut down
on mis-spellings, then using has_one is a great approach. But it does
mean another association, and that has a price to pay when you display
the parent, because you have to look up and cache all those values.
Another approach I have taken is to offload the complexity into the
edit view, since it’s not accessed nearly as often as the show. I use
a helper to create a “combo box” control for these sorts of fields,
which is loaded with an alphabetized and “uniqued” list of previously-
entered values, and ends in Other. Switching to Other causes a
JavaScript function to fire which replaces the picker with a text
field of the same name and ID. Blurring away from that field without
entering anything replaces the text field with the picker again.
The value is stored as a string, which then makes it available without
a separate or joined lookup into another table. So the user can enter
anything she likes, but gets to pick from a convenient list first to
avoid more typing.
Walter
What got me thinking was the idea that it would fire a lot a sql when
fetching a user. If i stored all data in the profile as string’s there
would
be less sql, right ?
I will keep the dropdown boxes and fill them from a model. But store
the data as strings instead of all has_one, or is the
ghost_of_many_sql_questions just
in my head ?
On Jun 6, 2011, at 2:11 PM, Niklas N. wrote:
What got me thinking was the idea that it would fire a lot a sql when
fetching a user. If i stored all data in the profile as string’s there
would
be less sql, right ?
That’s what I was saying. Even though there are optimizations to be
had with the joins, just grabbing the strings feels lighter to me.
Walter