¿Cuál es la diferencia entre los corchetes y las comillas simples para el alias en SQL Server?

sql-server quotes

Question

He visto algunos nombres de columnas de alias de personas utilizando comillas simples, por ejemplo:

select orderID ''Order No'' from orders

y otros usan corchetes, por ejemplo:

select orderID [Order No] from orders

Tiendo a usar corchetes. ¿Hay alguna preferencia / diferencia?

Answer 1

Depende de la configuración que tengas vigente, sea o no válida. Y te lo perdiste " . Ver identificadores delimitados :

Cuando QUOTED_IDENTIFIER se establece en ON, SQL Server sigue las reglas ISO para el uso de comillas dobles (") y la comilla simple ('') en las declaraciones SQL. Por ejemplo:

• Las comillas dobles solo se pueden utilizar para delimitar identificadores. No se pueden utilizar para delimitar cadenas de caracteres.

• Se deben usar comillas simples para encerrar cadenas de caracteres. No se pueden utilizar para delimitar identificadores.

Cuando QUOTED_IDENTIFIER se establece en OFF, SQL Server usa las siguientes reglas para las comillas simples y dobles:

• Las comillas no se pueden utilizar para delimitar identificadores. En su lugar, los corchetes deben utilizarse como delimitadores.

• Se pueden usar comillas simples o dobles para encerrar cadenas de caracteres.

Y finalmente:

Los delimitadores entre paréntesis siempre se pueden usar, independientemente de la configuración de QUOTED_IDENTIFIER

Donde, en todas las citas anteriores, cuando se refieren a corchetes, están hablando de corchetes [] .

Answer 2

El enfoque de cotización le permite hacer esto:

SELECT 1 AS ''bla[]bla''

Answer 3

Las comillas simples son más legibles. Como se demostró anteriormente, resaltado en rojo.

MySQL usa `backticks` para escapar de los caracteres especiales.

MSSQL puede usar "comillas dobles" o [corchetes] para los identificadores (tablas, columnas, etc.)
y ''comillas simples'' para cadenas de caracteres o alias.

Los corchetes se utilizan principalmente para encapsular objetos, de modo que los caracteres especiales como espacios, puntos o guiones no arrojan errores de sintaxis.

Recomendaría usar la palabra clave ''como'' antes de los alias de sus columnas, es mucho más legible.

select [column with spaces] as ''my col'' from "table with spaces" where n = ''foo''
select "column with spaces" as ''my col'' from [table with spaces] where n = ''foo''

Answer 4

Para responder a la pregunta "¿hay alguna preferencia / diferencia":

Sí, hay tantas preferencias como opiniones, pero tenga cuidado con las preferencias que adopte.

Como práctica recomendada, es recomendable escribir SQL portátil si no requiere ningún esfuerzo adicional.

Para su muestra específica, es tan fácil escribir una consulta portátil:

select OrderId as "Order Id" from Orders

Que escribir una no portátil:

select OrderId as [Order Id] from Orders

No es justificable escribir SQL no estándar cuando hay una forma portátil equivalente del mismo número de pulsaciones.

La proliferación de [] para escapar se debe a herramientas como SQL Server Management Studio y los constructores de consultas de MS Access, que se escapan de todo a la perfección. Es posible que nunca se le ocurra a un desarrollador que pasa su carrera en SQL Server, pero los paréntesis han ocasionado muchos gastos a lo largo de los años, al trasladar las aplicaciones de Access y SQL Server a otras plataformas de bases de datos. Lo mismo ocurre con las herramientas de Oracle que lo citan todo. Los desarrolladores no capacitados ven el DDL como ejemplos y luego continúan usando el mismo estilo cuando escriben a mano. Es un ciclo difícil de romper hasta que las herramientas mejoren y demandemos mejor. En Oracle, la cotización, combinada con una caja mixta, resulta en bases de datos que distinguen entre mayúsculas y minúsculas. He visto proyectos donde la gente citaba todos los identificadores en la base de datos, y tuve la sensación de que estaba en The Land of The Lost, donde los desarrolladores habían evolucionado en una isla sin documentación ni artículos de mejores prácticas.

Si escribe su DDL, desde el principio, con identificadores legales normalizados (use OrderId o order_Id en lugar de [Id. De pedido], no se preocupe por la palabra clave mítica que puede necesitar caracteres de escape; la base de datos le informará cuando He usado una palabra reservada. Puedo contar con un dedo las veces que hemos actualizado una aplicación de una versión de SQL Server a otra y tuve alguna rotura debido a nuevas palabras reservadas.

Este es a menudo el tema de un debate acalorado, por lo que si lo piensa de otra manera:

Los programadores de C # no escapan a todas sus variables con @, aunque es legal hacerlo. Eso sería considerado una práctica extraña, y sería objeto de ridículo en . El escape debe ser para los casos de borde. Pero a los mismos desarrolladores que escriben identificadores de C # conformes no les importa escapar de cada identificador en su SQL, escribiendo un "código" de SQL terriblemente feo y no portátil. Como consultor, he conocido a más de un programador de SQL Server que, honestamente, pensaba que [] era una sintaxis requerida. No culpo a los desarrolladores, culpo a las herramientas.