Quelle est la différence entre crochets et guillemets simples pour l'alias dans SQL Server?
J'ai vu des noms de colonne alias de certaines personnes utiliser des guillemets simples, par exemple:
select orderID 'Order No' from orders
et d'autres utilisent des crochets, par exemple:
select orderID [Order No] from orders
J'ai tendance à utiliser des crochets. Y a-t-il une préférence/différence?
Pour répondre à la question "y a-t-il une préférence/différence":
Oui, il y a autant de préférences qu'il y a d'opinions, mais faites attention aux préférences que vous adoptez.
Comme meilleure pratique, il est conseillé d'écrire du SQL portable s'il ne nécessite aucun effort supplémentaire.
Pour votre échantillon spécifique, il est tout aussi facile d'écrire une requête portable:
select OrderId as "Order Id" from Orders
Que d'en écrire un non portable:
select OrderId as [Order Id] from Orders
Il n'est pas justifié d'écrire du code SQL non standard lorsqu'il existe une forme portable équivalente du même nombre de touches.
La prolifération de [] pour l'échappement est due à des outils comme SQL Server Management Studio et les constructeurs de requêtes MS Access, qui échappent paresseusement à tout. Cela peut ne jamais arriver à un développeur qui passe sa carrière dans SQL Server, mais les supports ont causé de nombreuses dépenses au fil des ans pour le portage des applications Access et SQL Server vers d'autres plateformes de base de données. Il en va de même pour les outils Oracle qui citent tout. Les développeurs non formés voient la DDL comme exemples, puis utilisent le même style lors de l'écriture à la main. C'est un cycle difficile à briser jusqu'à ce que les outils s'améliorent et que nous demandions mieux. Dans Oracle, la citation, combinée à une casse mixte, donne des bases de données sensibles à la casse. J'ai vu des projets où les gens citaient chaque identifiant dans la base de données, et j'avais l'impression d'être dans The Land of The Lost où les développeurs avaient évolué sur une île sans documentation ni articles sur les meilleures pratiques.
Si vous écrivez votre DDL, dès le départ, avec des identifiants normalisés et légaux (utilisez OrderId ou order_Id au lieu de [Order Id], vous ne vous inquiétez pas du mot-clé mythique qui pourrait avoir besoin de caractères d'échappement; la base de données vous informera lorsque vous J'ai utilisé un mot réservé. Je peux compter sur un doigt les fois où nous avons mis à niveau une application d'une version de SQL Server à une autre et que nous avons eu des ruptures en raison de nouvea mots réservés.
C'est souvent le sujet d'un débat houleux, donc si vous y pensez autrement:
Les programmeurs C # n'échappent pas à toutes leurs variables avec @, même s'il est légal de le faire. Cela serait considéré comme une pratique étrange et ferait l'objet d'un ridicule sur StackOverflow. L'évasion devrait être pour les cas Edge. Mais les mêmes développeurs qui écrivent des identifiants C # conformes ne craignent pas d'échapper à chaque identifiant unique dans leur SQL, écrivant un "code" SQL terriblement laid et non portable. En tant que consultant, j'ai rencontré plus d'un programmeur SQL Server qui pensait honnêtement que [] était la syntaxe requise. Je ne blâme pas les développeurs, je blâme les outils.
Cela dépend des paramètres que vous avez en vigueur, que 's sont valides ou non. Et vous avez manqué ". Voir Identifiants délimités :
Lorsque QUOTED_IDENTIFIER est défini sur ON, SQL Server suit les règles ISO pour l'utilisation de guillemets doubles (") et le guillemet simple (') dans les instructions SQL. Par exemple:
Les guillemets doubles ne peuvent être utilisés que pour délimiter les identificateurs. Ils ne peuvent pas être utilisés pour délimiter des chaînes de caractères.
Des guillemets simples doivent être utilisés pour entourer les chaînes de caractères. Ils ne peuvent pas être utilisés pour délimiter des identifiants.
Lorsque QUOTED_IDENTIFIER est défini sur OFF, SQL Server utilise les règles suivantes pour les guillemets simples et doubles:
Les guillemets ne peuvent pas être utilisés pour délimiter les identificateurs. Au lieu de cela, les crochets doivent être utilisés comme délimiteurs.
Des guillemets simples ou doubles peuvent être utilisés pour entourer des chaînes de caractères.
Et enfin:
Les délimiteurs entre parenthèses peuvent toujours être utilisés, quel que soit le paramètre de QUOTED_IDENTIFIER
Où, dans toutes les citations ci-dessus, quand ils se réfèrent à des crochets, ils parlent de [] supports.
Les guillemets simples sont plus lisibles. Comme démontré ci-dessus, surligné en rouge.
MySQL utilise des `backticks` pour échapper les caractères spéciaux.
MSSQL peut utiliser des "guillemets doubles" ou des [crochets] pour les identifiants (tableaux, colonnes, etc.)
et "guillemets simples" pour les chaînes de caractères ou les alias.
Les crochets sont principalement utilisés pour encapsuler des objets afin que les caractères spéciaux tels que les espaces, les points ou les tirets ne génèrent pas d'erreurs de syntaxe.
Je recommanderais d'utiliser le mot clé 'as' avant les alias de vos colonnes - il est beaucoup plus lisible.
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'
L'approche par devis vous permet de faire ceci:
SELECT 1 AS 'bla[]bla'