Что стандарт SQL говорит об использовании backtick (`)?

Стандарт SQL (текущая версия - ISO/IEC 9075: 2011, в нескольких частях) ничего не говорит о символе "back-tick" или "back-quote" (Unicode U + 0060 или GRAVE ACCENT); он не распознает его как символ со специальным значением, который может появляться в SQL.

Стандартный механизм SQL для цитирования идентификаторов - это идентификаторы с разделителями, заключенные в двойные кавычки:

SELECT "select" FROM "from" WHERE "where" = "group by";

В MySQL это может быть написано:

SELECT `select` FROM `from` WHERE `where` = `group by`;

В MS SQL Server это может быть написано:

SELECT [select] FROM [from] WHERE [where] = [group by];

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

Microsoft применила один подход; MySQL взял другое; Informix позволяет сменное использование одинарных и двойных кавычек, но если вы хотите ограниченные идентификаторы, вы устанавливаете переменную среды, а затем вы должны следовать стандарту (одинарные кавычки для строк, двойные кавычки для идентификаторов); DB2 следует только стандарту AFAIK; Стандарт SQLite соответствует стандарту; Похоже, что Oracle придерживается стандарта; По-видимому, Sybase допускает либо двойные кавычки (стандартные), либо квадратные скобки (как в случае с MS SQL Server &mdash, что означает, что SQL Server также может использовать двойные кавычки). Эта страница документирует все эти серверы (и была полезной для заполнения пробелов в моих знаниях) и отмечает, чувствительны ли к строкам идентификаторы с разделителями или нет.

---

Что касается того, когда использовать механизм цитирования вокруг идентификаторов, мое отношение "никогда". Ну, не совсем никогда, но только тогда, когда это абсолютно необходимо.

Обратите внимание, что идентификаторы с разделителями чувствительны к регистру; то есть "from" и "from" относятся к разным столбцам (в большинстве СУБД - см. URL выше). Большая часть SQL не чувствительна к регистру; неудобно знать, какой случай использовать. (Стандарт SQL имеет ориентацию мэйнфрейма, поэтому ожидается, что имена будут преобразованы в верхний регистр, но большинство СУБД конвертируют имена в нижний регистр.)

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

Одним из продолжающихся источников проблем является обновление, когда имя столбца, которое не было ключевым словом в выпуске N, становится ключевым словом в версии N + 1. Существующий SQL, который работал до обновления, перестает работать после этого. Затем, по крайней мере, в качестве краткосрочной меры, вы можете быть вынуждены указать имя. Но в обычном ходе событий вы должны стремиться избегать цитирования идентификаторов.

Конечно, мое отношение окрашено тем фактом, что Informix (в основном это то, с чем я работаю) принимает этот SQL-запрос, тогда как большинство СУБД задушили его:

CREATE TABLE TABLE
(
    DATE    INTEGER NOT NULL,
    NULL    FLOAT   NOT NULL,
    FLOAT   INTEGER NOT NULL,
    NOT     DATE    NOT NULL,
    INTEGER FLOAT   NOT NULL
);

Конечно, человек, который производит такой смешной стол для чего-либо другого, кроме демонстрационных целей, должен быть висели, нарисованы, расквартированы, а затем должен быть сделан остаток, чтобы исправить беспорядок, который они создали. Но в некоторых пределах, которые клиенты обычно удаются, ключевые слова могут использоваться как идентификаторы во многих контекстах. Это само по себе является полезной формой будущей проверки. Если слово становится ключевым словом, существует умеренная вероятность того, что существующий код будет продолжать работать без изменений. Однако механизм не идеален; вы не можете создать таблицу с столбцом PRIMARY, но вы можете изменить таблицу, чтобы добавить такой столбец. Существует причина идиосинкразии, но ее трудно объяснить.