#mysql
#mysql
Вопрос:
На самом деле это происходит в производственной системе (не было ни в разработке, ни в производственных тестах).
У меня есть students.motherCPF/fatherCPF
оба значения int (11), и значение по умолчанию равно NULL, у students table engine есть InnoDB
, и на самом деле в нем 132 строки.
Значение в основном равно NULL, затем обновляется до одной отправленной мысленной HTML-формы и проходит через обработку в PHP. Это происходит при регистрации учащегося. Запрос на обновление уже сброшен, и значения передаются правильно.
Дело в том, что в базе данных значения неверны. В некоторых строках они отображаются как 2147483647, в других — как другие цифры, и все они неверны. CPF в Бразилии расшифровывается как Персональный регистрационный номер, представляющий собой 11-значное число, которое подобно идентификатору, поэтому оно уникально и персонально. Я видел 2147483647 более чем в 10 строках, и он всегда равен в столбцах motherCPF и fatherCPF.
Я уже пробовал обновлять напрямую через phpMyAdmin, через систему PHP, и ничего не происходит. Ошибок нет, затронуто 0 строк и никаких изменений. Пользователь базы данных является root и имеет необходимые привилегии. Я только не удалил таблицу и не создал заново, потому что в ней уже есть 132 строки.
Кто-нибудь знает, что происходит?
С базой данных все в порядке, только эти 2 столбца сошли с ума.
Комментарии:
1.
2147483647
максимальное значение для 32-разрядных целых чисел со знаком. Столбец подписан или без знака?2. общее неверное толкование того,
int(11)
что значение max равно99999999999
, что неверно.
Ответ №1:
В MySQL INT(11)
спецификатор означает, что он отформатирован так, как если бы в нем было 11 мест, но у него нет возможности хранить 11 произвольных цифр. Фактически вы достигаете предела значения со знаком.
Переключение на BIGINT
может обойти эту проблему стороной, но для «чисел», подобных этому, вы можете захотеть использовать что-то другое, например VARCHAR(255)
. Используйте числовые поля только для чисел, которые вы на самом деле вычисляете, таких как суммы, годы, цены и тому подобное. Для «числовых идентификаторов» или идентификаторов, которые просто состоят из цифр, вы можете захотеть придерживаться VARCHAR
, чтобы избежать проблем, подобных этой.
Сегодня это может быть 11 цифр, но затем неожиданно из-за какого-то нового бюрократического правила завтра это будет 12, или, может быть, 14 цифр плюс две буквы по причинам, которые вы даже не можете понять. Вы не хотите, чтобы ваше приложение делало слишком много предположений о будущем.
Комментарии:
1.«В MySQL спецификатор INT (11) означает, что он отформатирован так, как будто в нем 11 мест»,
INT(11)
имеет (некоторый) смысл только при использовании вместе с опцией ZEROFILL2. @RaymondNijland Ну, это имеет и другие последствия, но в основном косметические.
INT(1)
может по-прежнему сохранять те же значения, что иINT(11)
, приVARCHAR(1)
усечении. Не уверен, почему это так, MySQL кажется здесь очень причудливым.3. @RaymondNijland В этом случае вам не нужно было бы заполнять нулем, это могло бы испортить данные.
4. «В этом случае вам не нужно было бы заполнять нулем, это могло бы испортить данные». я никогда этим не пользовался и никогда не буду, лучший совет также для всех остальных
5. @RaymondNijland не может с этим поспорить.