Faz sentido usar a notação de colchete do SQL Server em código escrito à mão?

Os geradores de código tendem a ser mais simples quando geram saída usando a nova notação de colchete da Microsoft ( []) para quase tudo.

Quando o vi pela primeira vez, fiquei impressionado com a reencarnação da notação de identificador citada, um tanto banida.

Até onde eu sei, é uma extensão proprietária da Microsoft (o que significa que a Oracle não a suporta).

Olhando para o SQL Server, não há diferença se você definir uma tabela como

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

ou

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

É uma questão de estilo pessoal ou corporativo. Ser consistente.

Agora, se você deseja migrar seu banco de dados para Oracle, os colchetes não são uma opção.

Você pode usar os identificadores citados antigos, mas estes diferenciam maiúsculas de minúsculas, o que causa muitos problemas.

É uma boa idéia remover todos os colchetes do código gerado, evitar usar espaços em branco, outros caracteres especiais e palavras-chave reservadas para nomes e apenas codificar da maneira que a maioria dos DBMS entende?

O SQL padrão usa aspas duplas "para identificadores entre aspas. O SQL Server suporta isso usando a QUOTED_IDENTIFIERopção ( ANSI_QUOTESno mySQL). O SQL padrão melhora a portabilidade em geral e, nesse caso, seria portado para o Oracle. Da mesma forma, eu alteraria as palavras-chave do SQL para maiúsculas (requisito SQL-92 intermediário) e expandiria intpara INTEGER( requisito SQL-92 intermediário ).

O desnecessário uso de identificadores citados, qualquer que seja o sabor, deve ser evitado, IMO.

Esse é um problema subjetivo, mas os colchetes desnecessários estão perto do topo da minha lista de irritações de animais de estimação - um pouco mais irritante do que com erros ortográficos "! =", Mas não tão ruins quanto as vírgulas iniciais nas listas de colunas.

Objetivamente, considere o objetivo dos colchetes: permitir nomes de objetos que não seriam legais de outra forma. Dado esse objetivo, os colchetes são, na pior das hipóteses, um cheiro de código e, na melhor das hipóteses, um sinal de preguiça.

• Parênteses são necessários se os nomes de sua tabela ou coluna:

  • conter um espaço: SELECT [column name] FROM table;
  • conter um suporte:, SELECT [wt[f]ouSELECT [wt]]f]
  • contêm um símbolo não alfanumérico como ^ou !(sim, eles podem conter esses símbolos!)
  • são palavras-chave reservadas como KEY, STATE, RULE, ...

  Obviamente, se você tiver controle sobre o esquema, evite usar nomes como estes. No entanto, em alguns casos, o melhor nome é reservado (como KEYna coluna de chave em uma tabela de valor-chave genérica), então cabe a você decidir o quanto deseja usá-lo (e, portanto, citá-lo em todos os lugares).

  Também uso colchetes para suprimir o destaque azul que o SSMS e o VS fornecem algumas palavras-chave como DESCRIPTIONessas não reservadas pelo SQL Server, mas são especiais para essas ferramentas.

• Definitivamente use colchetes ao gerar dinamicamente SQL. A maneira mais fácil de fazer isso é chamando QUOTENAME()os objetos que você está referenciando dinamicamente (por exemplo SELECT QUOTENAME(name) FROM sys.databases;). sp_MSforeachdb, por exemplo, não faz isso .

Quando escrevo código que gera código, coloco colchetes em torno dos nomes dos objetos de banco de dados. Não incluo os colchetes ao escrever o código manualmente e acho que isso prejudica a legibilidade do código. Também proíbo nomes de objetos de banco de dados com espaços. O SQL Server permitirá que você use espaços nos nomes dos objetos, mas isso não significa que é uma coisa boa.

Eu provavelmente nem tentaria ter DDL portátil. Seria melhor se eu gerasse definições de tabela Oracle fora das visualizações do sistema do SQL Server, se necessário.

Também não acho que faça sentido escrever DML portátil - o PL / SQL é totalmente diferente do T-SQL. Para portabilidade, é mais fácil expor seu banco de dados por meio de uma API de procedimentos armazenados. As assinaturas desses procedimentos devem ser as mesmas nas duas plataformas, mas as implementações podem usar recursos proprietários - no geral, isso é muito mais fácil do que tentar usar apenas o SQL padrão ANSI.

Esta conclusão é baseada em vários anos de experiência no desenvolvimento de sistemas portáteis, trabalhando no Oracle e no SQL Server.