SQL: лучший способ хранить значения да / нет?Забота о производительности в огромных базах данных

Question

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

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

Это правильная мысль?Или это не влияет на производительность запросов к базе данных, когда используются только такие слова, как «да», «нет», «активный», «неактивный», «подозрительный» и т. Д.

заранее спасибо.

Answer 1

Семантически, я предлагаю вам использовать bit, если он вам доступен.Глядя на столбец, любой другой разработчик может сразу определить, что в нем хранится логическое значение.Если у вас нет bit, попробуйте использовать tinyint.Обеспечение согласованности означает, что 1 является единственным значением true, а 0 является единственным значением false.В противном случае вы можете получить беспорядочную смесь true / false, yes / no, valid / invalid, y / n и / или t /f.

Сравнение значений bit или tinyint, вероятно, не медленнее, чем сравнение строк, и даже если это было медленнее, чем сравнение строк, я не могу себе представить, что это оказывает существенное влияние на общеескорость.

Answer 2

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

Answer 3

Есть что-то, что вам не нравится в битовом типе данных?

Answer 4

Вы просто спрашиваете в общем, каков наиболее эффективный способ хранения флага да / нет?Или у вас есть проблемы с производительностью?

Если да, то когда у вас есть проблемы с производительностью (конкретные запросы, вставки, обслуживание и т. Д.)?Какое повышение производительности вы ищете?2%?10%?50%?

Изменение типов данных, скорее всего, приведет лишь к незначительному улучшению, если мы не говорим о нескольких сотнях миллионов строк.Я приведу вам пример.Допустим, что независимо от того, что вы сделали, вы сбрили по 3 байта на строку.Допустим, таблица содержит 100 000 000 строк.Это будет экономия ~ 285 МБ.Предполагая, что дисковая подсистема может предоставить вам 100 Мбит / с, вы сэкономили колоссальные 3 секунды для полного сканирования таблицы.Что-то подсказывает мне, что пользователи считают, что 2 часа и 3 секунды против 2 часов одинаковы:)

Answer 5

Если ваша СУБД поддерживает растровые индексы, каждый раз выбирайте BIT.Если это не так, используйте все, что вы хотите, на самом деле нет разницы между char (1) и tinyint (byte)

Answer 6

Моя интуиция сказала бы, что производительность была бы лучше с tinyints, но этот пост на самом деле не раскрывает эту мысль. Этот пост SO также предлагает некоторые другие интересные мнения.

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