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

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

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

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

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

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

Ответ 1

Я бы назвал колонку "пол".

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: CHAR (1).

Добавление

Вероятно, индекс по столбцу пола не поможет, поскольку в столбце с низким количеством элементов нет значения. Это значит, что значения индекса недостаточно для обеспечения какого-либо значения.

Ответ 2

Для этого уже существует стандарт ИСО; нет необходимости изобретать собственную схему:

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

В стандарте столбец должен быть назван "Пол", а "ближайший" тип данных будет иметь tinyint с ограничением CHECK или справочной таблицей.

Ответ 3

В медицине есть четыре пола: мужской, женский, неопределенный и неизвестный. Возможно, вам не нужны все четыре, но вам, безусловно, нужны 1, 2 и 4. Это не подходит для значения по умолчанию для этого типа данных. Еще меньше, чтобы рассматривать его как булевое с состояниями "есть" и "не является".

Ответ 4

An Int (или TinyInt), совпадающий с полем Enum, будет моей методологией.

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

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

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

Записывать операторы MySQL для создания таблицы с именем ADMISSION, используя следующий. Название столбца Название столбца Тип Длина Имя студента Sname Char 25 Пол Мужской Boolean

Дата рождения Dob Date

Сборы, выплачиваемые сборы Десятичная

введите описание изображения здесь

Ответ 8

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

если requuried: IsUnknownGender (1 = Да /0 = Нет) и так далее...

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

Ответ 9

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;

введите ссылку здесь