Сохранение пола (пола) в базе данных

Я хочу сохранить пол пользователя в базе данных с минимальными затратами (размер / производительность).

Пока на ум приходят 3 сценария

1. Int - выровнено с Enum в коде (1 = Мужской, 2 = Женский, 3 = ...)
2. char (1) - сохранить m , f или другой односимвольный идентификатор
3. Бит (логический) - есть ли подходящее имя поля для этой опции?

Я спрашиваю потому , что из этого ответа , который упоминает , что символы имеют меньше , чем булевы .

Я должен уточнить , что я использую MS SQL 2008, который делает на самом деле имеют битовый тип данных.

Колонку я бы назвал «пол».

Data Type   Bytes Taken          Number/Range of Values
------------------------------------------------
TinyINT     1                    255 (zero to 255)
INT         4            -       2,147,483,648 to 2,147,483,647
BIT         1 (2 if 9+ columns)  2 (0 and 1)
CHAR(1)     1                    26 if case insensitive, 52 otherwise

Тип данных BIT может быть исключен, поскольку он поддерживает только два возможных пола, что неадекватно. Хотя INT поддерживает более двух вариантов, он занимает 4 байта - производительность будет лучше с меньшим / более узким типом данных.

CHAR(1)имеет преимущество перед TinyINT - оба занимают одинаковое количество байтов, но CHAR предоставляет более узкое количество значений. Использование CHAR(1)приведет к использованию естественных ключей «m», «f» и т. Д. По сравнению с использованием числовых данных, которые называются суррогатными / искусственными ключами. CHAR(1)также поддерживается в любой базе данных, если возникнет необходимость в переносе.

Вывод

Я бы использовал вариант 2: СИМВОЛ (1).

добавление

Индекс в столбце пола, скорее всего, не поможет, потому что в индексе в столбце с низкой мощностью нет значения. Это означает, что для индекса недостаточно разнообразия значений, чтобы обеспечить какое-либо значение.

Для этого уже существует стандарт ISO; не нужно придумывать свою схему:

http://en.wikipedia.org/wiki/ISO_5218

Согласно стандарту, столбец должен называться «Пол», а «ближайший» тип данных - tinyint с ограничением CHECK или таблицей поиска, в зависимости от ситуации.

В медицине есть четыре пола: мужской, женский, неопределенный и неизвестный. Возможно, вам не понадобятся все четыре, но вам определенно понадобятся 1, 2 и 4. Не рекомендуется использовать значение по умолчанию для этого типа данных. Тем более рассматривать его как логическое значение с состояниями «есть» и «не».

Int(Или TinyInt) выравниваются по Enumполю будет моя методика.

Во-первых, если у вас есть одно bitполе в базе данных, строка по-прежнему будет использовать полный байт, так что с точки зрения экономии места это окупается, только если у вас есть несколько bitполей.

Во-вторых, строки / символы имеют для них «магическое значение», независимо от того, насколько очевидными они могут казаться во время разработки. Не говоря уже о том, что это позволяет людям хранить практически любую ценность, которую они не обязательно сопоставят с чем-то очевидным.

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

Я использую char 'f', 'm' и 'u', потому что предполагаю пол по имени, голосу и разговору, а иногда и не знаю его. Окончательное решение - это их мнение.

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

Вариант 3 - ваш лучший выбор, но не все движки БД имеют "битовый" тип. Если у вас нет немного, то TinyINT будет вашим лучшим выбором.

CREATE TABLE Admission (
    Rno INT PRIMARY KEY AUTO_INCREMENT,
    Name VARCHAR(25) NOT NULL,
    Gender ENUM('M','F'),
    Boolean_Valu boolean,
    Dob Date,
    Fees numeric(7,2) NOT NULL
);




insert into Admission (Name,Gender,Boolean_Valu,Dob,Fees)values('Raj','M',true,'1990-07-12',50000);
insert into Admission (Name,Gender,Boolean_Valu,Dob,Fees)values('Rani','F',false,'1994-05-10',15000);
select * from admission;

введите описание ссылки здесь

Я бы выбрал вариант 3, но с несколькими столбцами битов NON NULLABLE вместо одного. IsMale (1 = Да / 0 = Нет) IsFemale (1 = Да / 0 = Нет)

если требуется: IsUnknownGender (1 = Да / 0 = Нет) и так далее ...

Это упрощает чтение определений, простоту расширения, простоту программирования, отсутствие возможности использования значений вне домена и отсутствие необходимости во второй таблице поиска + ограничения FK или CHECK для блокировки значений.

РЕДАКТИРОВАТЬ: Исправление, вам нужно хотя бы одно ограничение, чтобы убедиться, что установленные флаги действительны.