Application design question (Application Theory)

rubyonrails-talk
1

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 ?

2

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

3

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 ?

4

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