boolean типы - Какой тип данных MySQL используется для хранения логических значений




пример 5.7 (10)

На этот вопрос был дан ответ, но я решил, что заброшу свои 0,02 доллара. Я часто использую CHAR (0), где '' == true и NULL == false.

Из документов mysql

CHAR (0) также неплохо, если вам нужен столбец, который может принимать только два значения: столбец, который определен как CHAR (0), NULL занимает только один бит и может принимать только значения NULL и '' (пустая строка) ,

Поскольку у MySQL, похоже, нет какого-либо «булевского» типа данных, какой тип данных вы «злоупотребляете» для хранения истинной / ложной информации в MySQL?

Особенно в контексте написания и чтения из / в PHP-скрипт.

Со временем я использовал и видел несколько подходов:

  • tinyint, varchar, содержащие значения 0/1,
  • поля varchar, содержащие строки '0' / '1' или 'true' / 'false'
  • и, наконец, перечислить поля, содержащие два параметра: «true» / «false».

Ничто из перечисленного не кажется оптимальным. Я предпочитаю вариант tinyint 0/1, поскольку автоматическое преобразование типов в PHP дает мне логические значения довольно просто.

Итак, какой тип данных вы используете? Есть ли тип, предназначенный для булевых значений, которые я забыл? Вы видите какие-либо преимущества / недостатки, используя тот или иной тип?


Это изящное решение, которое я вполне понимаю, потому что он использует нулевые байты данных:

some_flag CHAR(0) DEFAULT NULL

Чтобы установить значение true, установите some_flag = '' и установите для него значение false, задайте some_flag = NULL .

Затем, чтобы проверить значение true, проверьте, не является ли some_flag IS NOT NULL , и для проверки на false, проверьте, является ли some_flag IS NULL .

(Этот метод описан в разделе «Высокопроизводительная MySQL: оптимизация, резервное копирование, репликация и многое другое» Джона Уоррена Ленца, Барона Шварца и Арьена Ленца).


Если вы используете тип BOOLEAN, это псевдоним TINYINT (1). Это лучше всего, если вы хотите использовать стандартизованный SQL и не против, чтобы поле могло содержать значение вне диапазона (в основном все, что не равно 0, будет «истинным»).

ENUM («False», «True») позволит вам использовать строки в вашем SQL, а MySQL будет хранить это поле внутри себя как целое число, где «False» = 0 и «True» = 1 на основе порядка Enum ,

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

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


Бит полезен только по различным байтовым опциям (tinyint, enum, char (1)), если у вас много логических полей. Одно битовое поле по-прежнему занимает полный байт. Два битовых поля вписываются в тот же самый байт. Три, четыре, пять, шесть, семь, восемь. После чего они начинают заполнять следующий байт. В конечном итоге экономия настолько мала, что вам нужно сосредоточиться на тысячах других оптимизаций. Если вы не имеете дело с огромным количеством данных, эти несколько байтов не будут сильно отличаться. Если вы используете бит с PHP, вам нужно придать значения значениям входов и выходов.


BOOL и BOOLEAN являются синонимами TINYINT(1) . Zero является false , все остальное true . Дополнительная информация here .


Прочитав ответы здесь, я решил использовать bit(1) и да, это как-то лучше в пространстве / времени, НО через некоторое время я передумал, и я больше никогда не буду использовать его. Это очень усложняло мое развитие при использовании подготовленных операторов, библиотек и т. Д. (Php).

С тех пор я всегда использую tinyint(1) , кажется достаточно хорошим.


Я использую TINYINT (1) для хранения логических значений в Mysql.

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

http://dev.mysql.com/doc/refman/5.0/en/other-vendor-data-types.html


Для MySQL 5.0.3 и выше вы можете использовать BIT . В руководстве написано:

Начиная с MySQL 5.0.3, тип данных BIT используется для хранения значений битового поля. Тип BIT (M) позволяет хранить значения M-бит. M может варьироваться от 1 до 64.

В противном случае, согласно руководству MySQL, вы можете использовать bool и boolean, которые в настоящий момент являются псевдонимами tinyint (1):

Bool, Boolean: Эти типы являются синонимами для tinyint (1). Значение нуля считается ложным. Ненулевые значения считаются истинными.

MySQL также заявляет, что:

Мы намерены реализовать полную обработку булевых типов в соответствии со стандартным SQL в будущей версии MySQL.

Ссылки: dev.mysql.com/doc/refman/5.5/en/numeric-type-overview.html

BTW: это всего лишь вопрос https://google.com/search?q=mysql+boolean+datatype .

Смешно, не так ли, эта ссылка, опубликованная несколько лет назад, стала рекурсивной.


Обращаясь к этой ссылке Boolean datatype в Mysql , в зависимости от использования приложения, если требуется только 0 или 1 для хранения, бит (1) является лучшим выбором.


Я не рекомендую использовать ни поле DATETIME, ни TIMESTAMP. Если вы хотите представить определенный день в целом (например, день рождения), используйте тип DATE, но если вы более конкретны, вы, вероятно, заинтересованы в записи фактического момента, а не единицы время (день, неделя, месяц, год). Вместо использования DATETIME или TIMESTAMP используйте BIGINT и просто сохраните количество миллисекунд с эпохи (System.currentTimeMillis (), если вы используете Java). Это имеет ряд преимуществ:

  1. Вы избегаете блокировки поставщика. Практически каждая база данных поддерживает целые числа относительно похожим образом. Предположим, вы хотите перейти в другую базу данных. Хотите ли вы беспокоиться о различиях между значениями DATETIME MySQL и том, как Oracle их определяет? Даже среди разных версий MySQL, TIMESTAMPS имеют разный уровень точности. Совсем недавно MySQL поддерживал миллисекунды в метках времени.
  2. Нет проблем с часовым поясом. Здесь были некоторые проницательные комментарии о том, что происходит с часовыми поясами с разными типами данных. Но разве это общее знание, и ваши коллеги все время будут учиться этому? С другой стороны, довольно сложно перепутать BigINT в java.util.Date. Использование BIGINT приводит к множеству проблем с часовыми поясами, которые падают на обочину.
  3. Не беспокойтесь о диапазонах или точности. Вам не нужно беспокоиться о том, что будет сокращено будущими диапазонами дат (TIMESTAMP - только 2038).
  4. Интеграция сторонних инструментов. Используя целое число, тривиально для сторонних инструментов (например, EclipseLink) для взаимодействия с базой данных. Не каждый сторонний инструмент будет иметь такое же представление о «datetime», как это делает MySQL. Хотите попытаться выяснить в Hibernate, следует ли использовать объект java.sql.TimeStamp или java.util.Date, если вы используете эти настраиваемые типы данных? Использование базовых типов данных делает использование с сторонними инструментами тривиальным.

Эта проблема тесно связана с тем, как вы должны хранить денежную стоимость (т.е. 1,99 доллара США) в базе данных. Должны ли вы использовать Decimal или тип денег в базе данных, или, что хуже всего, Double? Все 3 из этих вариантов ужасны, по многим причинам, перечисленным выше. Решение заключается в том, чтобы хранить стоимость денег в центах с помощью BIGINT, а затем конвертировать центы в доллары, когда вы показываете значение для пользователя. Задача базы данных состоит в том, чтобы хранить данные и НЕ собирать данные. Все эти причудливые типы данных, которые вы видите в базах данных (особенно Oracle), мало добавляют и запускают вас по пути к блокировке поставщика.







mysql boolean sqldatatypes