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

Схема образует пространство имён внутри каталога базы данных, поэтому одинаковые имена таблиц допустимы в разных схемах. Однозначное обращение выполняется через составное имя схема.объект, например sales.orders и archive.orders.

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

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

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

Кроме организации объектов, схемы помогают разграничивать права. Например, приложению можно разрешить доступ к объектам схемы reporting, не предоставляя ему полный доступ к объектам схемы billing.

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

Предположим, в базе есть sales.orders и archive.orders. Если разработчик использует только orders, результат может зависеть от текущей схемы или списка схем поиска. Это создаёт риск чтения не тех данных, изменения неправильной таблицы либо удаления объекта с неожиданным именем.

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

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

Составное имя имеет форму схема.объект. Сначала СУБД находит указанную схему, затем объект с заданным именем внутри неё. Поэтому sales.orders и archive.orders — разные объекты, даже если их локальные имена совпадают.

CREATE SCHEMA sales;
CREATE SCHEMA archive;

CREATE TABLE sales.orders (order_id INTEGER);
CREATE TABLE archive.orders (order_id INTEGER);

ALTER TABLE sales.orders ADD COLUMN created_at DATE;
DROP TABLE archive.orders;

В примере ALTER TABLE изменяет только таблицу в схеме sales, а DROP TABLE удаляет только таблицу в archive. Наличие одинакового локального имени не смешивает их структуру, данные, ограничения или зависимости.

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

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

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

Команда архивирования создала схему archive с таблицей orders, повторяющей имя рабочей таблицы sales.orders. Миграция должна была добавить индекс только к архивным данным.

Рассматривались два варианта:

использовать неквалифицированное имя orders: запись короче, но результат зависит от контекста соединения и настроек поиска схем;
использовать archive.orders: запись немного длиннее, зато намерение однозначно и не зависит от текущей схемы.

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

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

Дополнительный вопрос: Что произойдёт, если схема, указанная в составном имени, не существует?

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

Дополнительный вопрос: Гарантирует ли одинаковое имя таблицы в другой схеме одинаковую структуру и ограничения?

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

Дополнительный вопрос: Почему полная квалификация имени не отменяет проверку прав доступа?

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