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

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

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

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

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

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

Предположим, существуют таблицы sales.orders и archive.orders. Запрос к orders может обратиться к одной из них в зависимости от настроек соединения или правил конкретной СУБД.

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

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

Сначала СУБД анализирует имя объекта и применяет собственные правила поиска. В PostgreSQL, например, порядок задаётся параметром search_path: будет выбрана первая схема из этого списка, в которой найден объект с подходящим именем. В других СУБД используются иные понятия, например схема по умолчанию пользователя или текущая схема.

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

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

CREATE SCHEMA sales;
CREATE SCHEMA archive;
CREATE TABLE sales.orders (id integer);
CREATE TABLE archive.orders (id integer);

SET search_path TO archive, sales;
SELECT * FROM orders;
SELECT * FROM sales.orders;

В первом запросе будет использована archive.orders, потому что archive стоит раньше sales. Второй запрос однозначно обращается к sales.orders независимо от search_path.

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

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

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

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

Рассматривались два варианта. Первый — сохранить короткие имена и централизованно задавать search_path: это уменьшает объём SQL-кода, но оставляет зависимость от настроек соединения. Второй — квалифицировать имена в запросах и миграциях: это требует правок, зато делает цель запроса явной.

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

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

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

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

Меняет ли квалификация имени способ проверки прав доступа?

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

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

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