Нормализует ли гендерная таблица слишком далеко?

Я не парень базы данных, но пытаюсь очистить другую базу данных. Итак, мой вопрос заключается в том, чтобы нормализовать гендерную таблицу слишком далеко?

User table:
userid int pk,
genderid char(1) fk
etc...

gender table:
genderid char(1) pk,
gender varchar(20)

Теперь сначала мне показалось глупо, но потом я подумал об этом, потому что теперь у меня есть постоянный источник данных для заполнения или привязки. Я буду использовать WPF. Если бы это была другая структура, я бы, вероятно, избежал ее, но что вы думаете?

Ответ 1

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

Я бы нормализовал, если:

Вы хотите иметь возможность управлять "описанием" пола в базе данных, а не кодом.
- Это позволяет вам быстро изменить описание от мужчины/женщины к мужчине/женщине, например.
В настоящее время ваше приложение должно обрабатывать или, возможно, обрабатывать в будущем требования к локализации, то есть указывать пол на разных языках.
Ваш бизнес требует, чтобы все было нормализовано.

Я бы не нормализовал, если:

У вас есть относительно простое приложение, в котором вы можете легко управлять описанием пола в коде, а не в базе данных.
У вас есть жесткий программный контроль за данными, поступающими из гендерного поля и из него, чтобы вы могли обеспечить согласованность данных в этом поле.
Вам нужно только заняться гендерным полем для сбора информации, то есть вам не нужно много программной необходимости обновлять это поле после его установки в первый раз.

Ответ 2

Я тоже не парень базы данных, но я это делаю. Это дает мне возможность гарантировать, что введены только полы, которые являются действительными (референциальная целостность), и я также могу использовать его для заполнения элемента управления выбором.

Ответ 3

Я могу думать о приложениях, где я бы использовал разные столбцы для пола и пола, имел три значения для пола (мужчина/женщина/отказ от статуса) и шесть для пола (мужчины/женщины/транссексуалы мужчины/транссексуалы женщины/бесполые/отказаться от состояния). Конечно, я живу в Сан-Франциско, где существует общественное обсуждение проблем транссексуалов, в которых большая часть остального мира находится за кривой.

Дело в следующем: без веской причины думать иначе, я бы предположил, что любое упрощающее предположение, которое я сделал о демографии, было ограниченным и ограниченным. Стоимость разрыва секса на собственный стол сейчас небольшая и дорогая позже. Я бы не избежал небольших затрат на основе предположения.

Ответ 4

Ну, у вашей компании может быть требование, чтобы, если возможно, все было нормализовано.

Кроме того, в зависимости от бизнеса и данных, вам может потребоваться также включить трансгендеров, которые будут создавать 3 + гендерные группы (я не знаю, сколько их есть, не проверялось)

Ответ 5

Отмечу еще один аспект: сортировка. Обычно "М" сортируется после "F"; в проекте один раз таблица базы данных имела поле полов с любым из этих двух значений. Было желание иметь возможность сортировать результаты по полу (данные переписи) и еще одно предпочтение иметь "М" перед "F". Мое решение состояло в том, чтобы добавить отдельную таблицу поиска, присвоив значение "мужчина" идентификатору 0, а женский - идентификатору 1. Таким образом, запросы в основной таблице могут быть легко отсортированы в новом поле genderID.

Ответ 6

Просто подумал, что я бы высказал мнение здесь. @Ben McCormack имеет отличный ответ с небольшим предостережением: что касается локализации, иногда существуют более эффективные способы решения этой проблемы, чем значения, определенные непосредственно в вашей базе данных.

Например, вы указываете WPF. С .Net у вас есть различные ресурсы локализации, которые намного лучше подходят для управления различиями в том, следует ли испускать "Муж" или "Самек" (Чехия).

Предоставив встроенные функции локализации, вы не должны беспокоиться о том, что несколько записей базы данных определяют то же самое, что может затруднить отчетность.

Тем не менее, я бы предположил, что вы можете подумать, действительно ли "пол" - это то, что вам нужно. Пол определяется как "набор характеристик, отличающих мужчин и женщин".

На первый взгляд это звучит как ваш стандартный Мужской/Женский варианты; но это не так. Гендер намного сложнее, чем тот, который требует контекста, чтобы иметь смысл. Например, в контексте отношений у мужчины (по полу) может быть один из нескольких "полов": мужский, женский или даже нейтральный. Это независимо от того, какой секс является его партнером.

В контексте только отдельного лица мужчина (по полу) может быть мужским, женским, нейтральным, трансгендерным, интерсекс или любым из нескольких других вариантов, приемлемых для человека, заполняющего форму.

По крайней мере, один человек отметил, что гендер необходим для определения почетности, используемой в почтовых рассылках. Я бы предположил, что нет никакой связи между полом и этими почетными званиями. Например, женщина (по полу) может захотеть обратиться к г-же/мисс/миссис/д-р/мадам/профессор или даже к г-ну, если они находятся в процессе или закончили операцию, чтобы стать "мужчиной". Этот список ни в коем случае не является всеохватывающим и в любом случае намного лучше разрешить этому человеку выбирать, как они хотят быть адресованными.

Что приводит меня к моему последнему пункту: перед тем как собрать любую часть данных, у вас должна быть определенная причина ее наличия. Моя компания специализируется на сборе данных через онлайн-формы. Одна из вещей, которые мы делаем, - это посмотреть, что наши клиенты запрашивают и выходят из поля по полю, чтобы определить, используются ли данные в любом месте.

Чаще всего предприятие (компания/правительственный/и т.д.) запрашивает гораздо больше информации, чем им нужно. Это может иметь дополнительные последствия в случае утери, кражи или просто просмотра данных неавторизованными лицами. Кроме того, на человека заполняется бланк, заполняющий формы для каждого поля, которое они просят завершить.

Я рассказываю об этом, потому что "Пол" почти никогда не нужен для какой-либо нормальной системы. Вместо этого секс является лучшим классификатором, и даже тогда он имеет мало значения. Освобождение сайтов знакомств и правительственная перепись.

Ответ 7

Да. Я думаю, что вы можете использовать перечисление в коде и привязать его к нему.

null - unknow; 0 - мужчина; 1 - женщина;

или вы можете использовать тип bool для определения этого

null - unknow; true - мужчина; false - женщина