Краткий ответ

Добавление обязательного столбца к непустой таблице возможно, если для каждой существующей строки сразу определяется допустимое ненулевое значение. Обычно этого достигают объявлением значения по умолчанию; альтернативно новый столбец сначала создают допускающим NULL, заполняют, а затем устанавливают ограничение NOT NULL.

Если столбец добавляется сразу с ограничением NOT NULL, но без значения по умолчанию, существующие строки не смогут удовлетворить ограничению, поэтому операция должна завершиться ошибкой. Для пустой таблицы такая операция обычно допустима, поскольку проверять существующие строки не нужно.

Исторический контекст

ALTER TABLE появился как средство эволюции схемы без создания новой таблицы и ручного переноса всех данных. Это решает практическую проблему изменения структуры работающей базы по мере развития приложения.

Ограничения вроде NOT NULL позволяют описывать правила целостности непосредственно в схеме. Однако изменение схемы должно учитывать уже существующие записи: новое правило обязано быть совместимо с данными, которые были записаны до изменения.

Постановка проблемы

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

Неверный порядок изменения может привести к откату DDL-операции, блокировкам или просто к отказу миграции. Даже успешное добавление столбца с default может потребовать заметных ресурсов: конкретное СУБД может физически переписать таблицу, перестроить строки или взять длительную блокировку.

Подробное решение

При добавлении столбца нужно обеспечить инвариант: после завершения операции значение нового столбца не должно быть NULL ни в одной существующей строке. Есть три основных варианта:

добавить столбец допускающим NULL, заполнить значения и затем установить NOT NULL;
добавить столбец с подходящим DEFAULT и NOT NULL;
если таблица пуста, добавить NOT NULL без default.

Минимальный пример:

CREATE TABLE orders (
    order_id INTEGER PRIMARY KEY
);

INSERT INTO orders VALUES (1);

-- Для непустой таблицы требуется значение для старой строки
ALTER TABLE orders
    ADD COLUMN priority INTEGER NOT NULL DEFAULT 0;

В примере существующая строка получает логическое значение 0, поэтому ограничение NOT NULL остается выполнимым. Для новых строк default применяется, когда значение priority не указано; явная передача NULL при этом по-прежнему нарушает NOT NULL.

Есть важное различие между логическим результатом и физической реализацией. Одни СУБД могут хранить постоянный default как метаданные и не переписывать всю таблицу, другие версии или другие системы могут перестроить таблицу. Поэтому миграцию нужно проверять с учетом конкретной СУБД, размера таблицы, блокировок и типа default-выражения.

Постепенная миграция часто безопаснее: сначала добавить nullable-столбец, затем заполнить его пакетами, проверить отсутствие NULL, после чего установить NOT NULL. Этот вариант уменьшает риск долгой блокировки, но временно оставляет схему менее строгой и требует контроля, чтобы приложение не создавало новые строки без корректного значения.

Ситуация из практики

В таблице заказов несколько сотен миллионов строк нужно добавить обязательный признак приоритета. Вариант с немедленным NOT NULL DEFAULT прост и атомарен, но может вызвать длительную блокировку или переписывание таблицы. Вариант с nullable-столбцом безопаснее для доступности, однако на промежуточном этапе приложение и база допускают неполные данные.

Команда выбирает поэтапную миграцию: добавляет столбец как nullable, обновляет строки небольшими пакетами, запрещает приложению создавать записи без значения, проверяет результат и только затем добавляет NOT NULL. Это дольше по числу шагов, но снижает риск простоя и позволяет откатить отдельный этап без потери исходных данных.

Результат — строгое ограничение в финальной схеме и контролируемая нагрузка во время миграции. Если конкретная СУБД гарантирует быстрый metadata-only default для постоянного значения, прямой вариант может быть предпочтительнее, но это должно подтверждаться документацией и тестом на соответствующей версии.

Что кандидаты часто упускают

1. Достаточно ли значения по умолчанию, чтобы запретить NULL во всех случаях?

Нет. Default используется, когда столбец не указан или для него явно предусмотрено применение default, но он не заменяет явно переданный NULL. Ограничение NOT NULL отдельно проверяет итоговое значение и отклоняет строку с NULL.

2. Обязательно ли физически записывать default в каждую старую строку?

Нет, это зависит от реализации СУБД. Она может материализовать значения при переписывании таблицы или представить постоянный default логически, добавив физические значения позднее. Для разработчика важен логический контракт, а для эксплуатации — фактические блокировки, объем записи и длительность операции.

3. Почему поэтапное добавление nullable-столбца не является полностью эквивалентным немедленному NOT NULL?

Пока ограничение не установлено, база допускает строки с NULL. Значит, параллельный процесс, другая версия приложения или ручная запись могут нарушить целевое правило после массового заполнения. Нужно отдельно закрыть этот промежуток: изменить код записи, проверить данные и только затем включить NOT NULL; иначе финальная проверка может завершиться ошибкой или данные снова станут неполными.