¿Qué dice el estándar SQL sobre el uso de backtick (`)?

Question

Una vez que había pasado horas en la depuración de una simple consulta SQL usando mysql_query() en PHP/MySQL solo para darme cuenta de que había perdido el bactick alrededor del nombre de la tabla. Desde entonces, siempre lo había usado con nombres de tablas.

Pero cuando utilicé lo mismo en SQLite/C++, el símbolo ni siquiera se reconoce. Es confuso, ya sea para usar esto o no? ¿Qué dice el estándar sobre su uso?

Además, sería útil si alguien pudiera decirme cuándo usar las comillas y cuándo no. Me refiero a los valores y los nombres de los campos.

Answer 1

El estándar SQL (la versión actual es ISO/IEC 9075: 2011, en varias partes) no dice nada sobre el símbolo 'back-tick' o 'back-quote' (Unicode U + 0060 o GRAVE ACCENT); no lo reconoce como un personaje con un significado especial que puede aparecer en SQL.

el mecanismo estándar SQL para citar identificadores es con identificadores delimitados entre comillas dobles:

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

En MySQL, que puede escribirse:

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

En MS SQL Server, que podría ser escrito:

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

El problema con la notación de SQL Standard es que Los programadores de C se utilizan para encerrar cadenas entre comillas dobles, por lo que la mayoría de los DBMS utilizan comillas dobles como alternativa a las comillas simples reconocidas por el estándar. Pero eso te deja con un problema cuando quieres adjuntar identificadores.

Microsoft tuvo un enfoque; MySQL tomó otro; Informix permite el uso intercambiable de comillas simples y dobles, pero si desea identificadores delimitados, establece una variable de entorno y luego debe seguir el estándar (comillas simples para cadenas, comillas dobles para identificadores); DB2 solo sigue el estándar, AFAIK; SQLite parece seguir el estándar; Oracle también parece seguir el estándar; Sybase parece permitir comillas dobles (estándar) o corchetes (como con MS SQL Server —, lo que significa que SQL Server también puede permitir comillas dobles). Este documento page documenta todos estos servidores (y me ayudó a llenar los vacíos que yo sepa) y observa si las cadenas dentro de los identificadores delimitados distinguen entre mayúsculas y minúsculas o no.

---

En cuanto a cuándo utilizar un mecanismo de cotización alrededor de los identificadores, mi actitud es 'nunca'. Bueno, no del todo nunca, pero solo cuando estoy absolutamente forzado a hacerlo.

Tenga en cuenta que los identificadores delimitados distinguen entre mayúsculas y minúsculas; es decir, "from" y "FROM" se refieren a diferentes columnas (en la mayoría de los DBMS — ver la dirección URL arriba). La mayoría de SQL no distingue entre mayúsculas y minúsculas; es una molestia saber qué caso usar. (El estándar SQL tiene una orientación de mainframe — espera que los nombres se conviertan en mayúsculas; la mayoría de los nombres de conversión DBMS se escriben en minúsculas)

En general, debe delimitar los identificadores que son palabras clave de la versión de SQL que estás usando Eso significa la mayoría de las palabras clave en Standard SQL, además de los extras que forman parte de las implementaciones particulares que está utilizando.

Una fuente continua de problemas son las actualizaciones, donde un nombre de columna que no era una palabra clave en la versión N se convierte en una palabra clave en la versión N + 1. El SQL existente que funcionaba antes de la actualización deja de funcionar después. Entonces, al menos como una medida a corto plazo, puede verse obligado a citar el nombre. Pero en el curso normal de los acontecimientos, debe tratar de evitar la necesidad de citar identificadores.

Por supuesto, mi actitud es de color por el hecho de que Informix (que es lo que trabajo en su mayoría) acepta este SQL pie de la letra, mientras que la mayoría de los DBMS se ahogue en él:

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

Por supuesto, la persona Quien produce una mesa tan ridícula para cualquier cosa que no sea la demostración debe ser colgada, estirada, descuartizada y luego debe hacerse el resto para arreglar el desastre que han creado. Pero, dentro de algunos límites que los clientes habitualmente logran alcanzar, las palabras clave pueden usarse como identificadores en muchos contextos. Eso es, en sí mismo, una forma útil de prueba de futuro. Si una palabra se convierte en palabra clave, existe una posibilidad moderada de que el código existente continúe sin afectarse por el cambio. Sin embargo, el mecanismo no es perfecto; no puede crear una tabla con una columna llamada PRIMARY, pero puede modificar una tabla para agregar dicha columna. Hay una razón para la idiosincrasia, pero es difícil de explicar.