lemurryЗдравствуйте. Проектирую учебную БД (для общества защиты животных). Я сделала пол отдельной таблицей (id и значение). Я знаю, что пол - это достаточно сложный вопрос (я была в Таиланде, например), но в рамках моей задачи я предполагаю упрощенную модель.


Да, вопрос сложный.
Пол животного ? Или пол человека ?
И для каких целей ?
Если человека, то какой пол ? Физический (медицинский), сексопатологический, гражданский ... и т.п.


lemurry Проблема в том, что мой преподаватель настаивает, чтобы я убрала таблицу и использовала битовое поле, так как это лишний join.


Это однозначно бредовый критерий. Тем более очень плохо слышать это от преподавателя.
JOIN -- одна из самых лёгких операций в СУБД, она практически ничего не стоит. Поэтому экономить тут нечего.

lemurryМоя интуиция подсказывает, что таблица - это удобно и естественно, а лишний join - это не проблема для современных СУБД. Подскажите пожалуйста, есть ли какие-нибудь преимущества в способе с битовым полем? Заранее спасибо.


Преимущества -- проще запрос, казалось бы, но если при наличии справочника пола тебе придётся сделать JOIN и вместо ID пола
поставить его наименование, то в запросе без справочника нужно будет писать CASE-выражение для подстановки вместо идентификатора пола его показываемого пользователю значения. И это надо будет делать во всех запросах (правда, можно соорудить view).

Но, ещё раз, в принципе вопрос "домен vs справочник" очень сложный и он не имеет общего решения, его всегда нужно рассматривать в контексте конкретной задачи и его требований.

И с другой стороны -- справочник (отдельная таблица) -- решение универсальное, и приняв этот подход невозможно ошибиться.
Напротив, если поле сделать доменом, то при расширении списка значений домена придётся переделывать всю таблицу, в больших БД это очень сложная операция.

Кстати, есть промежуточное решение, которое сочетает достоинства двух -- делать справочник, но идентификаторы справочника делать с "говорящими" значениями, в данном случае 'M' и 'F' и возможно что-то ещё. Так можно сочетать и тот и другой подходы, и если это запрос не для пользователя -- не делать JOIN (хотя это и не страшно для СУБД, писать лишнее конечно же неудобно).

defragmentatorMSSQLAndDotNetа почему битовое?
он - она - оно
1 - 0 - null
?
Если заказчик хочет биты, пусть будут биты

Не, извините.
null -- это не значение, это отсутсвие значения.
Нельзя что-то кодировать NULL-ом, это грубая ошибка проектирования.