Есть ли причины не хранить логические значения в SQL как битовые типы данных?

Question

Есть ли причины не хранить логические значения в SQL как битовые типы данных без NULL? Я часто вижу их как целые числа без ограничений для ограничения значений 0 и 1, а также как строки с такими вещами, как T / F, True / False, yes / no и т. Д., Опять же, без ограничений. Не лучше ли хранить их как биты и не беспокоиться о дополнительных ограничениях? Что мне здесь не хватает?

Answer 1

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

• SQLServer: BIT
• Oracle: NUMBER (1) (или BOOLEAN в PL / SQL)
• MySQL: TINYINT (iirc BOOLEAN сопоставляется с этим автоматически)

Редактировать: Oracle BOOLEAN - это только PL / SQL, а не определение таблицы. Обновленный ответ, чтобы отразить это.

Answer 2

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

если бы у тебя был tinyint для начала, то ты не ... поверь мне, это происходит чаще, чем ты думаешь

Answer 3

Я часто вижу их как целые числа без ограничений, чтобы ограничить значения 0 и 1, и как строки с вещами как T / F, True / False, да / нет и т. д., опять без ограничений. Не так ли лучше хранить их как биты, а не приходится беспокоиться о дополнительных ограничения?

Да!

Что мне здесь не хватает?

На самом деле это должно быть "что мне здесь не хватает?" и ответ будет: здравый смысл .

Answer 4

Некоторые причины этого не включают:

Не все базы данных имеют битовый тип данных, поэтому вместо них вы должны использовать int, чтобы иметь возможность использовать разные бэкэнды

В некоторых базах данных нельзя индексировать битовые поля.

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

Answer 5

BIT - тип данных, обычно используемый для хранения значений BOOLEAN. Просто потому, что если BIT равен 1, то его истина, а 0 - ложь. Это так просто.

Answer 6

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

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

Answer 7

Когда я хочу логические значения в базе данных, я всегда использую битовый тип данных. В SQL они могут быть NULL. Но при запуске вашей программы вы должны учитывать, что bool (например, в C #) - это тип значения, который в этом случае не может быть NULL. Вам придется сравнить со значением System.DBNull.

Answer 8

Используйте Enum, если у вас более двух статусов.

Answer 9

Я пользуюсь немного. Но иногда я хочу иметь возможность возвращать false - или много значений true (например, сообщения об ошибках). Так что если я использую int вместо логического, я могу сделать что-то вроде:

0 = Ложь 1 = неверный пароль 2 = Имя пользователя не существует. 3 = Учетная запись заблокирована - для многих неудачных попыток. 4 = Учетная запись отключена.

И так далее.

Answer 10

Я думаю, что в третьей форме нормализации будет указано, что у вас должна быть таблица, в которой хранятся значения True и False, и ссылка на нее Убедитесь, что вы делаете это и со своими датами!

Но кто в любом случае полностью придерживается 3NF? ;)