It seems to me like it's designed so it could be queried reasonably easily -- with prefix LIKE queries, which will use the index (I'm assuming MySQL here, but presumably it's somewhat universal).
I'd keep it in a single column, and create named scopes to find other things in the same category etc. But who knows, you've thought about it more than me... On Fri, Nov 26, 2010 at 15:58, Bayan Khalili <[email protected]> wrote: > I guess you can have a single model which stores a complete hierarchy (the > four divisions) in separate columns, and point to that from your other model > with a foreign key. > Regards, > Bayan > On Fri, Nov 26, 2010 at 3:37 PM, Tim McEwan <[email protected]> wrote: >> >> As foreign keys? Or with all the codes stored as model constants? I'm >> not sure how I'd go about creating the hierarchical relationship this way - >> is it easily manageable from a user's perspective? >> Ideally I would also be able to create an interface to manage these codes. >> >> -- >> Tim McEwan >> Sent with Sparrow >> >> On Friday, 26 November 2010 at 15:30, Bayan Khalili wrote: >> >> Can you use four columns in your original model instead (division, >> sub_division, class, group)? >> Regards, >> Bayan >> >> On Fri, Nov 26, 2010 at 3:23 PM, Tim McEwan <[email protected]> wrote: >> >> Considering the potential purpose of this app, I think it'd be best to >> store it in parts to facilitate lookups by the different classifiers. Also >> the strings might change - the government revises them every 5 years or so, >> I believe. >> -- >> Tim McEwan >> Sent with Sparrow >> >> On Friday, 26 November 2010 at 15:18, Simon Russell wrote: >> >> Once your model has the code assigned, do you need to link to the code >> parts? Could you just store it as a string? (And use the hierarchy >> to help build up the string) >> >> On Fri, Nov 26, 2010 at 15:14, Tim McEwan <[email protected]> wrote: >> >> Hey guys, >> I have a model that has_one "ANZIC code". ANZIC codes are classifiers set >> by the gov that are 4 or fewer levels deep: division, sub-division, class >> & >> group. >> Most of the time, the objects we're tracking won't have an advertised >> code, >> so the data entry person will need to drill down into the classifications >> to >> hone in on the most appropriate code. I'm thinking 4 sequential select >> lists for UI. (Let me know if you've a better idea. :-) >> What about model-wise? I'm not keen on the idea of creating 3 has_many >> relationships, resulting in 4 look-up queries, but I also think a ne sted >> set >> may be overkill because this isn't n-levels deep, it's always 4 or less. >> How should it be designed so that it'll be easy to reference and easy to >> display the full compound code string? >> Please and thank you! >> >> -- >> Tim McEwan >> Sent with Sparrow >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" gro up. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
