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

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

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

В реляционных схемах одни и те же бизнес-понятия часто повторяются в разных таблицах: код валюты, положительная сумма, номер телефона или идентификатор внешней системы. Если в каждом столбце отдельно указывать базовый тип и одинаковый CHECK, определения постепенно расходятся.

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

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

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

Это создает риск неодинаковой валидации: данные одного назначения будут приниматься в одной таблице и отклоняться в другой. Однако домен не должен использоваться для правил вроде «дата окончания не раньше даты начала», потому что такое правило связывает два столбца и относится к таблице, а не к одному значению.

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

Домен является объектом схемы, который обычно задает базовый тип, а при необходимости — значение по умолчанию и ограничения. Столбец, объявленный через домен, получает его типовую основу и проверку доменных ограничений при записи или изменении значения.

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

CREATE TABLE invoices (
    invoice_total positive_amount,
    tax_total positive_amount
);

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

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

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

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

В платежной системе суммы использовались в шести таблицах. Сначала в каждой таблице применяли DECIMAL и локальный CHECK; после добавления нового сервиса одна таблица получила другое условие и начала принимать нулевые суммы.

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

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

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

Вопрос: Может ли домен заменить ограничение, проверяющее согласованность двух столбцов?

Ответ: Нет. Домен описывает отдельное значение и не предназначен для проверки отношения между столбцами одной строки. Условие вроде «нижняя граница не превышает верхнюю» должно задаваться ограничением CHECK таблицы, где доступны оба столбца.
Вопрос: Что произойдет, если домен используется в десятках столбцов, а его ограничение нужно ужесточить?

Ответ: Изменение становится централизованным, но потенциально затрагивает все зависимые столбцы. Сначала нужно проверить существующие данные на соответствие новому правилу, определить порядок миграции и учесть особенности конкретной СУБД: операция может потребовать блокировки или отдельного обновления данных.
Вопрос: Почему для каждого столбца нельзя ограничиться одинаковым CHECK вместо домена?

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