\
**Category:** Rails\
**Created:** [February 5, 2010, 4:08am UTC](https://www.ruby-forum.com/t/store-html-select-option-value/182946 "2010-02-05T04:08:03Z")\
**Posts on this page:** 4\
**Page:** 1
**Author:**  [@Learn\_by\_D](https://www.ruby-forum.com/u/Learn_by_D)\
**Post date:** [February 5, 2010, 4:08am UTC](https://www.ruby-forum.com/t/store-html-select-option-value/182946/1 "2010-02-05T04:08:03Z")
In my app, each user may have one of the 30 predefined occupations.
Each occupation is a string of about 30 characters. Should I:
a. store this list of occupations in a mysql table and make
occupation\_id a foreign key in the User model? OR
b. define this list as an array of constants in the User model?
In option b, the array definition will be long and take up space in my
user.rb file. Can I put it somewhere else?
I am leaning toward option a because in the future I may want to allow
each user to have more than one occupations. In that case, I will
need to have another table to map the many-to-many relationship
between users and occupations, right?
In the future, more occupations may be added to the list. I may also
try the autocomplete plugin.
Thanks,
Vincent.
---
**Author:**  [@Learn\_by\_D](https://www.ruby-forum.com/u/Learn_by_D)\
**Post date:** [February 5, 2010, 12:16pm UTC](https://www.ruby-forum.com/t/store-html-select-option-value/182946/2 "2010-02-05T12:16:28Z")
I agree, option A is better. Maintaining a hardcoded array of 30 cells
is cumbersome and less flexible.
---
**Author:**  [@Learn\_by\_D](https://www.ruby-forum.com/u/Learn_by_D)\
**Post date:** [February 5, 2010, 8:40pm UTC](https://www.ruby-forum.com/t/store-html-select-option-value/182946/3 "2010-02-05T20:40:08Z")
Thanks all. Now I have the confidence to move forward.
---
**Author:**  [@Learn\_by\_D](https://www.ruby-forum.com/u/Learn_by_D)\
**Post date:** [February 5, 2010, 4:56pm UTC](https://www.ruby-forum.com/t/store-html-select-option-value/182946/4 "2010-02-05T16:56:31Z")
On Feb 4, 10:06 pm, Vincent P [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> I am leaning toward option a because in the future I may want to allow
> each user to have more than one occupations. In that case, I will
> need to have another table to map the many-to-many relationship
> between users and occupations, right?
>
> In the future, more occupations may be added to the list. I may also
> try the autocomplete plugin.
Given the possible expansion to many-to-many, and the potential for
more - option A definitely makes more sense. Be aware that it’s not
_always_ the right way, though: I’ve got a legacy DB I’m working with
right now that contains DB tables for branches of the US armed forces
(silly, since they are unlikely to change) or even a table like this:
id =\> name
1 =\> First
2 =\> Second
3 =\> Third
Apparently some Access programmers haven’t heard of “helpers”…
–Matt J.