С точки зрения теории правильно для пола ( как впрочем и для имён, отчеств) делать отдельную таблицу.
однако все мы не без греха, и сплошь и рядом делаем денормализацию, правда, одни (опытные бойцы) осознанно,
другие (молодёжь) не осознанно. Тут можно привести житейскую мудрость: "Что-бы нарушать правила, их нужно очень хорошо знать".
Если вы решили денормализовать таблицу, то должны чётко осознавать, что вы делаете нарушение, и соответственно, принять все меры, что-бы быстро и безболезненно восстановить Status Quo.
Например, вы в черновом варианте БД создали таблицу PERSONNEL. Решили, что информацию о половой принадлежности будете хранить в поле SEX. сразу вопрос: "какой тип поля, строковой или целочисленный?"
Неопытный боец выберет строковой тип (это-же так удобно, сразу виден пол человека!) и в дальнейшем получит следующие грабли:
1. вместо ожидаемых им двух значений "М" и "Ж", через некоторое время в таблице он найдёт следующие варианты пола: "М"(рус), "Ж", "M"(англ), "м"(рус), "ж", "m"(англ), а так-же кучу прочего мусора. Валидация вводимых значений не поможет, так как user'ы задолбают ~ следующим: "Программа не работает, я жму на клавишу "M" (в английском регистре), а она ругается "
2. В один прекрасный день заказчик скажет: женщины у нас уходят на пенсию в 55лет, мужчины в 60, женщины уходят в декрет, а мужчины нет, в женский праздник 8 марта мы дарим цветы и конфеты, а на 23 февраля коньяк и конфеты. И всё, будете долгими зимними вечерами перелопачивать БД и приложение, приводя её к нормальному виду, т.е. добавляя таблицу SEX.

Опытный боец заранее продумает эту ситуацию, для поля SEX предпочтёт целочисленные значения (0,1), создаст в клиентском приложении соответствующую инфраструктуру. При необходимости (п.2), в течении нескольких минут создаст необходимую табл. SEX, из поля PERSONNEL.SEX сделает внешний ключ, и вуаля!