Est-il judicieux d'utiliser la notation entre crochets de SQL Server dans du code manuscrit?

Les générateurs de code ont tendance à être plus simples lorsqu'ils génèrent une sortie à l'aide de la nouvelle notation de support Microsoft ( []) pour presque tout.

Quand je l'ai vu pour la première fois, j'ai pensé à une réincarnation de la notation identifiée quelque peu interdite.

Pour autant que je sache, il s'agit d'une extension propriétaire de Microsoft (ce qui signifie qu'Oracle ne la prend pas en charge).

En regardant SQL Server, il n'y a pas de différence si vous définissez une table comme

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

ou

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

C'est une question de style personnel ou d'entreprise. Être cohérent.

Maintenant, si vous souhaitez migrer votre base de données vers Oracle, les crochets ne sont pas une option.

Vous pouvez utiliser les anciens identifiants cités, mais ceux-ci sont sensibles à la casse, ce qui cause beaucoup de problèmes.

Est-ce une bonne idée de supprimer tous les crochets du code généré, d'éviter d'utiliser des blancs, d'autres caractères spéciaux et des mots clés réservés pour les noms et juste du code d'une manière que la plupart des SGBD comprennent?

SQL standard utilise le guillemet double "pour les identificateurs entre guillemets. SQL Server prend cela en charge en utilisant l' QUOTED_IDENTIFIERoption ( ANSI_QUOTESdans mySQL). SQL standard améliore la portabilité en général et, dans ce cas, porterait sur Oracle. De même, je changerais les mots clés SQL en majuscules (exigence intermédiaire SQL-92) et développerais inten INTEGER(exigence SQL-92 d'entrée de gamme).

Il est inutile d'éviter d'utiliser des identifiants cités, quelle qu'en soit la saveur, OMI.

Il s'agit d'un problème subjectif, mais les crochets inutiles se trouvent en haut de ma liste de bêtes noires - légèrement plus ennuyeux que l'orthographe "! =", Mais pas aussi mauvais que les virgules de tête dans les listes de colonnes.

Objectivement parlant, considérons le but des crochets: autoriser des noms d'objets qui ne seraient pas légaux autrement. Dans ce but, les crochets sont au pire une odeur de code et un signe de paresse au mieux.

• Les parenthèses sont requises si les noms de vos tables ou colonnes:

  • contenir un espace: SELECT [column name] FROM table;
  • contenir une parenthèse:, SELECT [wt[f]ouSELECT [wt]]f]
  • contiennent un symbole non alphanumérique comme ^ou !(oui, ils peuvent contenir ces symboles!)
  • sont des mots - clés réservés comme KEY, STATE, RULE, ...

  Évidemment, si vous contrôlez le schéma, évitez d'utiliser des noms comme ceux-ci. Cependant, dans certains cas, le meilleur nom est un nom réservé (comme KEYpour la colonne clé dans une table générique clé-valeur), c'est donc à vous de décider dans quelle mesure vous voulez l'utiliser (et donc de le citer partout).

  J'utilise également des crochets pour supprimer la surbrillance bleue indiquant que SSMS et VS donnent certains mots clés comme DESCRIPTIONcelui-ci qui ne sont pas réservés par SQL Server mais sont par ailleurs spéciaux pour ces outils.

• Utilisez certainement des crochets lors de la génération dynamique de SQL. Le moyen le plus simple est de faire appel QUOTENAME()aux objets auxquels vous faites référence dynamiquement (par exemple SELECT QUOTENAME(name) FROM sys.databases;). sp_MSforeachdb, par exemple, ne fait pas cela .

Lorsque j'écris du code qui génère du code, je mets des crochets autour des noms d'objets de base de données. Je n'inclus pas les crochets lorsque j'écris du code à la main, et je trouve que cela nuit à la lisibilité du code. J'interdis également les noms d'objets de base de données avec des espaces. SQL Server vous permettra d'utiliser des espaces dans les noms d'objets, mais cela ne signifie pas que c'est une bonne chose.

Je n'essaierais probablement même pas d'avoir un DDL portable. Il serait préférable que je génère des définitions de table Oracle à partir des vues système de SQL Server, si nécessaire.

Je ne pense pas non plus qu'il soit logique d'écrire du DML portable - PL / SQL est totalement différent de T-SQL. Pour la portabilité, il est plus facile d'exposer votre base de données via une API de procédures stockées. Les signatures de ces procédures doivent être les mêmes sur les deux plates-formes, mais les implémentations peuvent utiliser des fonctionnalités propriétaires - dans l'ensemble, cela est beaucoup plus facile que d'essayer d'utiliser uniquement du SQL standard ANSI.

Cette conclusion est basée sur plusieurs années d'expérience dans le développement de systèmes portables, travaillant à la fois sur Oracle et SQL Server.