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 ?
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
On Jun 6, 2011, at 10:45 AM, Niklas Nson wrote:> 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 ?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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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 6 Juni, 18:03, Walter Davis <wa...-HQgmohHLjDZWk0Htik3J/w@public.gmane.org> wrote:> On Jun 6, 2011, at 10:45 AM, Niklas Nson wrote: > > > > > > > > > > > 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 ? > > 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-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Walter Davis
2011-Jun-06 19:01 UTC
Re: Re: Application design question (Application Theory)
On Jun 6, 2011, at 2:11 PM, Niklas Nson 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> > 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 6 Juni, 18:03, Walter Davis <wa...-HQgmohHLjDZWk0Htik3J/w@public.gmane.org> wrote: >> On Jun 6, 2011, at 10:45 AM, Niklas Nson wrote: >> >> >> >> >> >> >> >> >> >>> 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 ? >> >> 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 > > -- > You received this message because you are subscribed to the Google > Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails- > talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > . > For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en > . >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.