Well I'm trying to help you with best practice but you don't seem to get what I'm saying.
Originally Posted by Dyogenez
Exactly. Gender is simply an attribute of your user, not an entirely separate entity that needs modelling and its own database table.
How would you recommend storing it if not as a relation? As a varchar with the text of the option they selected?
If all you want to do is simply present a list of options for a particular attribute of your model, say in this case the gender attribute of your user model, simply code that into your form.
In your user form (view):
<%= select('user', 'gender', %w(Male Female Unspecified)] %>
Even with something like religion, it doesn't matter how many options there are, you will usually only want to list them directly in your HTML as above. Another example is a drop down list of countries. Lets say you have an Address model with an attribute called "country". Again, there is no need for a database table of countries, you simply create the list of options directly in your view. In the case of countries, as its such a common list and its so long, Rails does the hard work for you:
The only time you really need to store options in a database table of their own is if that list needs to be manipulated in some way by end users - for instance a backend function that allows administrators to add new options. But whenever you are dealing with a fixed set of options, there is no need for a model/database table.
<%= country_select 'address', 'country' %>
Finally, to take your religion example again, and lets assume you did need a database table of religions for some reason and therefore have a Religion model, there is still no need to do this:
If all you are doing is getting a list of religions from the database so you can display them in a select box, simply do (assuming your Religion model has a name property):
And then in your view:
@religions = Religion.find(:all)
That will create a select box tied to the religion property of your user model, with the options being created by looping through @religions and calling name() for the option text and id() for the option value. Example:
<%= collection_select 'user', 'religion', @religions, 'name', 'id' %>
The bottom line though, is always consider whether something is simply an attribute of a model or an entirely separate model in itself and does the list of possible options for that attribute need to be edited by the end user? Gender definately isn't a model as its simply a property with 3 possible values. Religion could be a model but it depends on the context. If all you are interested in is the religion name, then it need be no more than a property of your user model. If however you were storing more information on each religion (therefore it would have many attributes of its own) you might have a case for a separate model.
<!-- etc -->