Is it bad practice to implement a separate table consisting of only two rows Female and Male?

Question

Assume we have a Person table with 3 columns:

1. PersonId of type int. (Primary key)
2. Name of type string.
3. GenderId of type int (Foreign key referencing Gender table).

The Gender table consists of 2 columns:

1. GenderId of type int.
2. Name of type string.

My question is: Is it worth implementing the Gender table? Or it causes performance degradation? What is the best way to handle this?

Edit 1:

I have to populate a drop down control with a list of fixed genders (female and male) in my UI.

Answer 1

I think the best approach in this case is a compromise:

1. Create a table called Gender with a single varchar column called 'Name' or 'Gender'. Gender is really a natural primary key. Put the values 'Male' and 'Female' in it.
2. Create foreign key to your Person table on a column named 'Gender'.

Now you only need to query from one table, but you're still protected from data inconsistencies by the foreign key, and you can pull the values for your dropdown from the Gender table if you want to. Best of both worlds.

Additionally, it makes life easier for someone working in the database, because they don't need to remember which arbitrary ids you've assigned to Male/Female.

Answer 2

If you have a field with only two possible values, you don't need another table for it. You can just use something like a BIT (0=male, 1=female) or a CHAR ('M' and 'F').