Есть ли причины того, что не были сохранены булевы значения в SQL как типы данных bit?
Это просто означает следующее:
total = -valFromsp;
Строка кода представляет собой оператор присваивания с выражением в правой части, являющимся + - valFromsp. Что значит + - valFromsp? Если мы добавим скобки, он станет +(-(valFromsp)).
Унарный оператор - оперирует операндом valFromsp, делая его -60. И тогда унарный оператор + работает на -60, ничего не делая с ним.
Унарные операторы + и - определены в §15.15 спецификации языка Java:
Операторы +, -, ++, - , ~,! и оператор приведения (§15.16) называются унарными операторами.
blockquote>UnaryExpression: PreIncrementExpression PreDecrementExpression + UnaryExpression - UnaryExpression UnaryExpressionNotPlusMinusИспользование унарного оператора
+дополнительно определено в §15.15.3 :Унарное числовое продвижение ( §5.6.1 ) выполняется на операнде. Тип унарного выражения плюс является продвинутым типом операнда. Результатом унарного выражения плюс является не переменная, а значение, даже если результатом выражения операнда является переменная.
blockquote>Но так как вы используете
ints, которые не проходят унарное числовое продвижение,+ничего не делает. Даже если вы используетеbyte,shortилиchar,+все равно ничего не будет делать, потому что унарный оператор-также продвигает. Так что на самом деле нет никакой причины использовать одновременно+и-.Я предлагаю вам просто изменить его на:
total = -valFromsp;, чтобы избежать путаницы в будущем.
11 ответов
Я бы всегда использовал наименьший тип данных, который я могу сохранить.
- SQLServer: BIT
- Oracle: NUMBER (1 ) (или BOOLEAN в PL / SQL)
- MySQL: TINYINT (iirc BOOLEAN сопоставляется с этим автоматически)
Редактировать: Oracle BOOLEAN - только PL / SQL, а не определение таблицы. Обновленный ответ, чтобы отразить это.
, что обычно происходит в будущем, это то, что кто-то хочет добавить также, возможно, да и нет, если у вас есть немного, то теперь вы должны изменить весь свой код на tinyint
, если с самого начала у тебя был tinyint, тогда ты не ... поверь мне, это происходит чаще, чем ты думаешь
Я часто вижу их как целые числа без ограничений, чтобы ограничить значения 0 и 1, и как строки с вещами как T / F, True / False, да / нет и т. д., опять без ограничений. Не так ли лучше хранить их как биты, а не приходится беспокоиться о дополнительных ограничения?
Да!
Чего мне здесь не хватает?
На самом деле это должно быть «что я НЕ пропускаю здесь?» и ответ будет: здравый смысл .
Некоторые причины, по которым это не нужно делать, включают:
Не все базы данных имеют битовый тип данных, поэтому вместо них вы используете int, чтобы иметь возможность использовать разные бэкэнды
В некоторых Базы данных вы не можете индексировать битовые поля.
И часто то, что у вас есть, не является истинным / ложным, да / нет без других возможностей. Например, у вас может быть битовое поле для статуса, означающее что-то вроде открытого или закрытого. Но позже вы понимаете, что вам также нужно отменить статус.
Когда я хочу использовать логические значения в базе данных, я всегда использую битовый тип данных. В SQL они могут быть NULL. Но при запуске вашей программы вы должны учитывать, что bool (например, в C #) - это тип значения, который в этом случае не может быть NULL. Вам придется сравнить со значением System.DBNull.
Мы всегда храним данные как биты, они маленькие, и, что более важно, это тот случай, для которого они предназначены.
У нас были времена, когда конечный пользователь собирался работать с данными напрямую, и для них, Да / Нет или Y / N было более читабельным. В этом случае мы только что создали представление, которое отображало более дружественные данные.
BIT - это тип данных, обычно используемый для хранения значений BOOLEAN. Просто потому, что если BIT равен 1, то его истина, а 0 - ложь. Это так просто.
одной из причин является то, что люди не знают о битах и не думают, что y / n проще для форматирования. Другая причина в том, что иногда вы думаете: хм, может быть, со временем это будет больше, чем поле bool. и вы делаете это int на всякий случай.
вы ничего не упускаете :))
I think third normalization form would state that you should have a table that stores the values True and False, and reference that. Make sure you do that with your dates as well!
But who completely adheres to 3NF anyway? ;)
Я немного использую. Но иногда я хочу иметь возможность возвращать false - или много значений true (например, сообщения об ошибках). Так что если я использую int вместо логического, я могу сделать что-то вроде:
0 = False 1 = неверный пароль 2 = Имя пользователя не существует. 3 = Учетная запись заблокирована - для многих неудачных попыток. 4 = Учетная запись отключена.
И так далее.