¿Tiene sentido usar la notación de corchetes de SQL Server en el código escrito a mano?

Los generadores de código tienden a ser más simples cuando generan resultados utilizando la nueva notación de soporte de Microsoft ( []) para casi todo.

Cuando lo vi por primera vez, pensé en una reencarnación de la notación de identificador citado algo prohibido.

Hasta donde sé, es una extensión patentada de Microsoft (lo que significa que Oracle no lo admite).

Mirando a SQL Server no hay diferencia si define una tabla como

CREATE TABLE [dbo].[Table_2] ([col1] [int], [col2] [int]);

o

CREATE TABLE dbo.Table_2 (col1 int, col2 int);

Es una cuestión de estilo personal o corporativo. Se consistente.

Ahora, si desea migrar su base de datos a Oracle, los corchetes no son una opción.

Puede usar los identificadores citados anteriormente, pero estos distinguen entre mayúsculas y minúsculas, lo que causa muchos problemas.

¿Es una buena idea eliminar todos los corchetes del código generado, evitar el uso de espacios en blanco, otros caracteres especiales y palabras clave reservadas para los nombres y solo el código de una manera que la mayoría de los DBMS entiendan?

SQL estándar utiliza la comilla doble "para los identificadores entre comillas. SQL Server admite esto usando la QUOTED_IDENTIFIERopción ( ANSI_QUOTESen mySQL). El SQL estándar mejora la portabilidad en general y, en este caso, sería portador a Oracle. Del mismo modo, cambiaría las palabras clave de SQL a mayúsculas (requisito intermedio de SQL-92) y ampliaría inta INTEGER(requisito de nivel de entrada SQL-92).

No es necesario utilizar identificadores entre comillas, sea cual sea el sabor, IMO.

Este es un problema subjetivo, pero los corchetes innecesarios están cerca de la parte superior de mi lista de cosas que me molestan, un poco más molesto que escribir mal "! =", Pero no tan malo como las comas principales en las listas de columnas.

Hablando objetivamente, considere el propósito de los corchetes: permitir nombres de objetos que de otro modo no serían legales. Dado ese propósito, los corchetes son un olor a código en el peor de los casos, y un signo de pereza en el mejor de los casos.

• Se requieren paréntesis si los nombres de su tabla o columna:

  • contener un espacio: SELECT [column name] FROM table;
  • contener un corchete SELECT [wt[f], oSELECT [wt]]f]
  • contienen un símbolo no alfanumérico como ^o !(sí, ¡ pueden contener esos símbolos!)
  • son palabras clave reservadas como KEY, STATE, RULE, ...

  Obviamente, si tiene control sobre el esquema, evite usar nombres como estos. Sin embargo, en algunos casos, el mejor nombre es reservado (como KEYpara la columna de clave en una tabla genérica de clave-valor), por lo que depende de usted decidir cuánto desea usarlo (y, por lo tanto, debe citarlo en todas partes).

  También uso corchetes para suprimir el resaltado azul de que SSMS y VS dan algunas palabras clave como las DESCRIPTIONque SQL Server no reserva, pero que son especiales para esas herramientas.

• Definitivamente use paréntesis cuando genere SQL dinámicamente. La manera fácil de hacerlo es recurriendo QUOTENAME()a los objetos a los que hace referencia dinámicamente (por ejemplo SELECT QUOTENAME(name) FROM sys.databases;). sp_MSforeachdb, por ejemplo, no hace esto .

Cuando escribo código que genera código, pongo corchetes alrededor de los nombres de los objetos de la base de datos. No incluyo los corchetes cuando escribo el código a mano, y encuentro que resta valor a la legibilidad del código. También prohíbo nombres de objetos de bases de datos con espacios. SQL Server le permitirá usar espacios en los nombres de los objetos, pero eso no significa que sea algo bueno.

Probablemente ni siquiera trataría de tener DDL portátil. Sería mejor si generara definiciones de tabla de Oracle a partir de las vistas del sistema de SQL Server, si fuera necesario.

Tampoco creo que tenga sentido escribir DML portátil: PL / SQL es totalmente diferente de T-SQL. Para la portabilidad, es más fácil exponer su base de datos a través de una API de procedimientos almacenados. Las firmas de estos procedimientos deben ser las mismas en ambas plataformas, pero las implementaciones pueden usar características propietarias; en general, esto es mucho más fácil que tratar de usar solo SQL estándar ANSI.

Esta conclusión se basa en varios años de experiencia en el desarrollo de sistemas portátiles, trabajando tanto en Oracle como en SQL Server.