О выборе типа данных - PullRequest
       1

О выборе типа данных

2 голосов
/ 26 ноября 2010

Если в одном из моих столбцов в моей Таблице я хочу указать значения Да, Нет или Необязательно, какой тип данных мне нужно использовать?

Ответы [ 6 ]

9 голосов
/ 26 ноября 2010

BIT:

  • занимает 1 байт, но до 8 полей BIT можно объединить в один BYTE в SQL Server.
  • хранит одно из двух значений: 1 (означает «истина») и 0 (означает «ложь»), поэтому столбец должен быть обнуляемым, чтобы значение NULL передавалось как третье значение

CHAR(1)

  • занимает 1 байт
  • 26 символов, если регистр не учитывает ASCII, против 52, если он чувствителен к регистру

TINYINT

  • занимает 1 байт
  • значения от нуля до 255

Производительность

Все параметры занимают одинаковое количество места, что делает производительность эквивалентной для JOIN / и т.д.

Сравнение

BIT не самый мудрый выбор, если есть вероятность изменения возможных значений.CHAR(1) немедленно читается IE: Y, N, O. TINYINT является хорошим выбором для первичного ключа в таблице, к которой вы хотите обратиться через внешний ключ, и хранить описательный текст в другом столбце.

Вывод:

CHAR(1) будет моим выбором, если не использовать отношение внешнего ключа, TINYINT в противном случае.
При использовании CHAR (1) наличие первичного первичного ключа, состоящего из одного символа, оченьнавряд ли.Предполагать, что естественный ключ, основанный на главном символе, не работает, если у вас есть 2+ слова, начинающиеся с того же символа, и вызывает горе, если метка должна измениться, потому что ключ также должен меняться и сохраняться (если вы не ленивый и не любите объяснятьпочему код не следует той же схеме, что и другие).CHAR (1) также предоставляет примерно пятую часть возможностей (при условии, что верхний предел, 52 значения с учетом регистра), что делает TINYINT - искусственный / суррогатный ключ изолирует от изменений описания.

3 голосов
/ 27 ноября 2010

Я удивлен, увидев так много голосов за "Бит" здесь.Это плохой выбор.

Семантически, NULL означает «неизвестный», поэтому он не является хорошим выбором в качестве третьего (известного) значения.Если вы используете его таким образом, вы можете столкнуться с большим количеством проблем в будущем.Например, агрегатные функции, GROUP BY и объединения могут вести себя не так, как вы ожидаете.Пользовательские интерфейсы могут также не обрабатывать обработку NULL как значения (например, MS Access имеет проблемы с полями нулевого бита).Вы также не сможете помочь сохранить целостность данных, определив поле NOT NULL.

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

Перейти с CHAR или TinyInt.

3 голосов
/ 26 ноября 2010

Используйте BIT для True / False или в вашем случае используйте CHAR (1) Y / N или CHAR (3) Да / Нет.

Действительно, я бы использовал здесь CHAR (1), потому что дополнительный2 символа не добавляют никакой реальной стоимости.

0 голосов
/ 26 ноября 2010

Я согласен с опциями "OMG Ponies", но не для его заключения в этом случае.

Используйте битовый столбец! Наличие одного бита, назначенного для хранения данных, дает шесть бесплатных хранилищ Y / N / O и одно хранилище Y / N бесплатно. Когда используется тип данных Bit, всегда определяйте по крайней мере в битах как ненулевое значение, поэтому SQL зарезервирует место на странице данных для значений.

0 голосов
/ 26 ноября 2010

Я бы использовал char (1) или INT с проверочным ограничением.Просто чтобы минимизировать возможные несоответствия между базой данных и любым уровнем абстракции, который вы используете для доступа к ней.JDBC не имеет TINYINT, например.

0 голосов
/ 26 ноября 2010

И Сергей, и JonVD предлагают хорошие решения, но я согласен с Сергеем. Обнуляемый бит предлагает три варианта. Если это не ноль, то вы знаете, что пользователь выбрал опцию.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...