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

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

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

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

Домен не является отдельной таблицей и не хранит данные сам по себе. Он задаёт типизированный контракт, который используют столбцы разных объектов схемы.

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

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

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

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

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

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

Удаление ограничения домена не меняет значения в таблицах, но прекращает соответствующую проверку для будущих вставок и обновлений. Уже сохранённые значения автоматически не преобразуются и не пересматриваются как данные.

Изменение базового типа домена — более существенная операция. Она может потребовать проверки совместимости, преобразования значений или быть запрещена из-за зависимостей; точные детали зависят от конкретной СУБД. Поэтому домен удобен для единого правила, но создаёт более широкий радиус воздействия миграций.

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

CREATE DOMAIN positive_amount AS DECIMAL(10, 2)
    CHECK (VALUE >= 0);

CREATE TABLE invoices (
    amount positive_amount
);

ALTER DOMAIN positive_amount
    ADD CONSTRAINT upper_limit CHECK (VALUE <= 1000000);

После добавления ограничения upper_limit оно относится не только к invoices.amount, но и к каждому столбцу в любой таблице, использующему positive_amount. Если в таких столбцах уже есть значения больше миллиона, изменение домена не должно быть принято как обычное успешно валидированное изменение.

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

В платёжной системе домен currency_code использовался в таблицах счетов, возвратов и комиссий. Команда решила ограничить набор допустимых кодов дополнительным условием домена.

Вариант с добавлением ограничения к домену был выбран из-за единого правила и отсутствия дублирования. Недостаток — миграция стала зависеть от качества данных во всех таблицах, а не только в таблице текущего сервиса.

Альтернативой было добавить отдельные ограничения CHECK к нужным столбцам. Это уменьшило радиус воздействия, но создало риск расхождения правил и потребовало больше DDL-изменений. В итоге команда сначала проверила все зависимые столбцы, исправила данные, затем изменила домен в отдельной миграции; результатом стал единый проверяемый контракт без неожиданных отказов при развёртывании.

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

Вопрос: Изменение ограничения домена автоматически исправляет уже сохранённые значения?

Ответ: Нет. Ограничение проверяет допустимость значений, но не является преобразованием данных. Существующие строки остаются прежними; при добавлении более строгого правила они могут привести к отказу самой миграции, но не будут автоматически исправлены.
Вопрос: Чем изменение ограничения домена отличается от изменения ограничения отдельного столбца?

Ответ: Ограничение столбца действует в пределах одного столбца конкретной таблицы. Ограничение домена является общим для всех зависимых столбцов, поэтому одна DDL-операция меняет поведение нескольких объектов схемы. Это уменьшает дублирование, но увеличивает область потенциального воздействия.
Вопрос: Можно ли считать домен полностью независимым от таблиц, которые его используют?

Ответ: Нет. Между доменом и столбцами существуют зависимости схемы. СУБД учитывает их при изменении или удалении домена: операция может потребовать проверки совместимости, завершиться отказом при режиме RESTRICT или затронуть зависимые объекты при каскадном поведении. Поэтому домен нужно рассматривать как общий объект контракта, а не как локальный псевдоним типа.