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

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

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

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

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

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

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

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

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

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

Некавыченные имена обрабатываются по правилам конкретной СУБД. Например, в PostgreSQL имя ClientData без кавычек трактуется как clientdata, а имя в двойных кавычках сохраняется как ClientData.

-- PostgreSQL
CREATE TABLE "ClientData" (id integer);

SELECT * FROM "ClientData"; -- обращение к созданной таблице
SELECT * FROM ClientData;   -- поиск таблицы clientdata

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

Кавычки не являются частью имени объекта. Они лишь указывают способ разбора идентификатора. Если объект создан как разделённый идентификатор, при каждом обращении нужно повторять точное написание и заключать его в двойные кавычки.

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

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

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

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

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

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

Гарантирует ли указание схемы отсутствие проблемы с регистром?

Нет. Квалификация схемой устраняет неоднозначность между одноимёнными объектами в разных схемах, но не меняет правила идентификаторов. Если таблица создана с точным именем ClientData, компонент имени таблицы всё равно должен быть указан в правильном регистре и в двойных кавычках. То же правило применяется отдельно к имени схемы, если оно также было создано как разделённый идентификатор.

Можно ли использовать одинарные кавычки для обращения к объекту с особым именем?

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

Что произойдёт при переименовании объекта с кавычками?

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