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

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

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

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

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

Для этого в SQL предусмотрены обычные идентификаторы и идентификаторы с разделителями. Второй механизм позволяет использовать в имени символы или слова, которые нельзя безопасно интерпретировать как обычные идентификаторы.

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

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

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

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

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

CREATE SCHEMA sales;
CREATE TABLE sales."order" (
    order_id INTEGER PRIMARY KEY
);

SELECT order_id
FROM sales."order";

-- Обращение к sales.order без кавычек
-- может завершиться синтаксической ошибкой.

Квалификация sales."order" дополнительно указывает схему и уменьшает неоднозначность поиска объекта. Но квалификация не отменяет необходимость кавычек: sales.order всё равно содержит необрамлённое ключевое слово.

Имена в двойных кавычках обычно сохраняют указанный регистр и требуют последующего обращения с тем же написанием. Необрамлённые идентификаторы СУБД нормализует по своим правилам, поэтому нельзя без проверки переносить предположения о регистре между PostgreSQL, Oracle, MySQL, SQL Server и другими системами.

Есть три практических стратегии:

Переименовать объект в обычное имя — обычно лучший вариант для нового проекта.
Всегда использовать идентификатор с разделителями — допустимо при совместимости с существующей схемой.
Полагаться на особенности конкретной СУБД — наименее переносимый вариант.

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

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

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

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

Результатом стало предсказуемое выполнение существующих запросов без массовой миграции. Компромисс — дополнительная зависимость от правил конкретной СУБД и необходимость проверять генерацию SQL в ORM и инструментах миграций.

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

Можно ли заменить двойные кавычки одинарными?

Нет. Одинарные кавычки обозначают строковые литералы, а двойные — идентификаторы с разделителями. Подстановка одинарных кавычек превращает имя объекта в текстовое значение и не решает задачу обращения к таблице или столбцу.

Почему добавление схемы не решает конфликт с ключевым словом?

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

Почему цитирование имени может нарушить работу ORM или миграций?

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