Разбор последствий: к чему приведёт достижение максимального значения INTEGER в идентификаторе, если тип заранее не заменить на BIGINT?
После достижения диапазона INTEGER новые значения идентификатора нельзя будет корректно представить этим типом: СУБД обычно отклонит операцию из-за переполнения, хотя точное поведение зависит от реализации. Замена на BIGINT расширяет диапазон, но её нужно выполнить заранее: затронут сам столбец, внешние ключи, индексы, ORM-модели и интеграции.
Целочисленные типы появились как компактный способ хранить точные числа и эффективно индексировать их. Разные размеры типов позволяют выбирать компромисс между занимаемым пространством, производительностью и допустимым диапазоном значений.
Идентификатор часто начинают с INTEGER, потому что ожидаемое число записей кажется небольшим. Однако срок жизни системы, поток архивных и технических записей, а также использование идентификатора в нескольких таблицах могут привести к тому, что первоначальная оценка окажется неверной.
У INTEGER есть конечный диапазон. Когда генератор идентификаторов пытается выдать значение за его пределами, вставка может начать завершаться ошибкой, а проблема проявится именно в рабочем процессе создания новой записи.
Простая замена типа в одной таблице недостаточна. Если на идентификатор ссылаются внешние ключи, несовместимые типы могут помешать изменению схемы или создать риск ошибок в приложении и миграциях.
BIGINT обычно предоставляет существенно больший диапазон, но конкретные границы и стоимость хранения определяются СУБД. При миграции нужно согласованно изменить первичный или уникальный ключ, все внешние ключи, связанные индексы и типы параметров в приложении.
Важна также совместимость генератора значений. Если идентификатор получает значение из последовательности, identity-механизма или другого генератора, его диапазон и тип должны поддерживать новый столбец. Само изменение типа не исправит генератор, который продолжает выдавать значения ограниченного диапазона.
Откладывать миграцию до переполнения опасно: к этому моменту запись новых данных уже может быть невозможна. Безопаснее оценить прогнозируемое количество значений, проверить поддержку BIGINT во всех компонентах и выполнить изменение заранее, желательно с контролем блокировок и времени выполнения DDL.
Переход сразу к NUMERIC не всегда лучше. Он даёт более широкий диапазон, но может занимать больше места и быть менее удобным или быстрым для ключей, чем машинный целочисленный тип. Для обычного монотонно растущего идентификатора BIGINT обычно является более естественным выбором, если он поддерживается всей технологической цепочкой.
В системе заказов ключ таблицы заказов был объявлен как INTEGER, а значение выдавалось identity-механизмом. После нескольких лет работы прогноз показал, что диапазон будет исчерпан раньше планового срока из-за массового импорта исторических заказов.
Рассматривались три варианта. Оставить INTEGER было проще всего, но это лишь переносило аварийную остановку. Перейти на NUMERIC давало запас, однако требовало проверки производительности индексов и совместимости драйверов. Перейти на BIGINT требовало изменить ключи и внешние ссылки, зато сохраняло семантику целого машинного идентификатора.
Выбрали BIGINT и провели согласованную миграцию всех связанных столбцов, генератора и моделей приложения. Изменение выполнили до исчерпания диапазона, поэтому новые заказы продолжили создаваться без аварийного переключения в условиях нагрузки.
Нет. Все внешние ключи, хранящие значения этого идентификатора, должны быть совместимы с новым типом. Нужно также проверить индексы, промежуточные таблицы, ETL-процессы, API-контракты и типы переменных в приложении.
Нет. BIGINT только значительно расширяет диапазон представимых целых чисел. Он не предотвращает ошибки генератора, ручные конфликты, некорректное восстановление резервной копии или повторную выдачу уже использованного значения. Уникальность по-прежнему должна обеспечиваться ограничением ключа и корректной стратегией генерации.
Не всегда. Конкретная СУБД может заблокировать таблицу, перепроверить ограничения или перестроить индекс; длительность зависит от размера данных и реализации DDL. Поэтому нужно изучить поведение используемой СУБД, оценить блокировки, подготовить план отката и отдельно проверить изменение всех зависимых объектов.