Слишком далеко заходит нормализация гендерной таблицы?
Я не парень в базе данных, но пытаюсь очистить другую базу данных. Так что мой вопрос заключается в том, не слишком ли далеко зашла бы нормализация гендерной таблицы?
User table:
userid int pk,
genderid char(1) fk
etc...
gender table:
genderid char(1) pk,
gender varchar(20)
Сначала мне это показалось глупым, но потом я подумал об этом, потому что тогда у меня может быть постоянный источник данных для заполнения или привязки. Я буду использовать WPF. Если бы это была другая структура, я бы, вероятно, избежал этого, но что вы думаете?
6 ответов
Независимо от того, решите ли вы нормализовать структуру таблицы с учетом пола , это будет зависеть от требований вашего приложения и бизнес-требований.
Я бы нормализовал, если:
- Вы хотите иметь возможность управлять «описанием» пола в базе данных, а не в коде.
- Это позволяет быстро изменить описание, например, с «Мужчина / Женщина» на «Мужчина / Женщина».
- Ваше приложение в настоящее время должно обрабатывать или, возможно, будет обрабатывать в будущем требования локализации, то есть возможность указывать пол на разных языках.
- Ваш бизнес требует, чтобы все было нормализовано.
Я бы не стал нормализовать, если:
- У вас есть относительно простое приложение, в котором вы можете легко управлять описанием пола в коде, а не в базе данных.
- У вас есть жесткий программный контроль над входящими и исходящими данными в поле пол , так что вы можете гарантировать согласованность данных в этом поле.
- Вас интересует только поле пол для сбора информации, а это означает, что вам не нужно много программной необходимости обновлять это поле после того, как оно будет установлено в первый раз.
Я тоже не специалист по базам данных, но я этим занимаюсь. Это дает мне возможность убедиться, что введены только те полы, которые действительны (ссылочная целостность), и я также могу использовать его для заполнения элемента управления выбором.
Что ж, у вашей компании может быть требование, чтобы, если возможно, все было нормализовано.
Кроме того, в зависимости от бизнеса и данных, вам может потребоваться включить трансгендеров, что создаст 3+ пола (я не знаю, сколько их, не проверял)
Отмечу еще один аспект: сортировка. Обычно «M» ставится после «F»; в одном проекте таблица базы данных имела поле пола с любым из этих двух значений. Было желание иметь возможность сортировать результаты по полу (данные переписи), а также было предпочтение, чтобы буква «М» появлялась перед буквой «F». Мое решение заключалось в том, чтобы добавить отдельную таблицу поиска, присвоив значению Male идентификатор 0, а женщине - идентификатор 1. Таким образом, запросы в основной таблице можно было легко отсортировать по новому полю гендерного идентификатора.
Да. Я думаю, что вы можете использовать enum в коде и в конечном итоге привязаться к нему.
null - неизвестно; 0 - самец; 1 - женский;
или вы можете использовать тип bool для определения этого
null - неизвестно; правда - самец; false - женский
Я могу вспомнить приложения, в которых я бы использовал разные столбцы для пола и пола, имел три значения для пола (мужской / женский / отказ от заявленного) и шесть для пола (мужской / женский / транссексуальный мужчина / транссексуальный женский / асексуальный /отказаться от состояния). Конечно, я живу в Сан-Франциско, где существует уровень публичного обсуждения проблем трансгендеров, от которого отстает большая часть остального мира.
Дело в том, что без веских причин думать иначе, я бы предположил, что любое упрощающее предположение, которое я сделал о демографии, было ограниченным и ограниченным. Стоимость того, чтобы заняться сексом за его собственным столом, сейчас невелика, а позже - дорого. Я бы не стал избегать небольших затрат на основе предположений.