Utiliser des backticks autour des noms de champ


172

Après avoir lu quelques réponses et commentaires sur certaines questions SQL ici, et entendu également qu'un de mes amis travaille dans un endroit qui a une politique qui les interdit, je me demande s'il y a quelque chose de mal à utiliser des backticks autour des noms de champs dans MySQL .

C'est:

SELECT `id`, `name`, `anotherfield` ...
-- vs --
SELECT id, name, anotherfield ...

24
sont vraiment à portée de main des accents graves si vous voulez avoir les noms de colonnes comme count, type, tableou similaire
Knittl


@knittl Je pense que la question est, devrait vous avoir des noms de colonnes comme count, typeet table. Ce sont des termes terriblement ambigus et dans presque tous les cas, ces noms pourraient être améliorés pour être plus précis. Nommer vos colonnes des choses comme ça est également dangereux et une source potentielle d'erreurs, car vous ne savez jamais quand quelqu'un pourrait oublier d'ajouter les backticks ou ne pas se rendre compte qu'il doit le faire. Je pense qu'il vaut mieux éviter d'utiliser des termes réservés comme noms de colonnes.
dallin

Je les utilise toujours et je ne suis donc pas en danger d'avoir utilisé des mots-clés réservés à tout moment.
Markus Zeller

Réponses:


153

L'utilisation de backticks vous permet d'utiliser des caractères alternatifs. Dans l'écriture de requêtes, ce n'est pas un tel problème, mais si l'on suppose que vous pouvez simplement utiliser des backticks, je suppose que cela vous permet de vous en sortir avec des choses ridicules comme

SELECT `id`, `my name`, `another field` , `field,with,comma` 

Ce qui génère bien sûr des tables mal nommées.

Si vous êtes juste concis, je ne vois pas de problème avec cela, vous remarquerez si vous exécutez votre requête en tant que telle

EXPLAIN EXTENDED Select foo,bar,baz 

L'avertissement généré qui revient aura des contre-graduations et des noms de table complets. Donc, si vous utilisez des fonctionnalités de génération de requêtes et une réécriture automatisée des requêtes, les backticks rendraient l'analyse de votre code moins confuse.

Je pense cependant qu'au lieu de demander si vous pouvez ou non utiliser des backticks, ils devraient avoir une norme pour les noms. Cela résout des problèmes plus «réels».


Avons-nous besoin de les utiliser également dans PostgreSQL?
Yousuf Memon

5
Il n'y a pas besoin, seulement une recommandation. Il est utile de les représenter entre guillemets pour éviter toute ambiguïté avec les mots-clés SQL si à l'avenir, un mot-clé SQL est ajouté qui partage le nom de vos champs. Le seul moment où vous / besoin / de citation est lorsqu'un champ fait partager un nom mot - clé, par exemple, select count from foovs select "count" from foodonnera des résultats très différents. Mais postgres diffère de mysql de deux manières: 1. Les champs sont indiqués par "". 2. Les champs non cotés sont insensibles à la casse postgresql.org/docs/current/static/…
Kent Fredric

57

Le seul problème avec les backticks est qu'ils ne sont pas compatibles ANSI-SQL, par exemple ils ne fonctionnent pas dans SQL Server.

S'il y a une chance que vous deviez porter votre SQL vers une autre base de données, utilisez des guillemets doubles.


15
Oui. Utilisez le mode ANSI de MySQL - dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html - pour activer les guillemets doubles dans MySQL et ainsi retrouver la compatibilité entre les bases de données. Les backticks / guillemets sont également nécessaires car vous ne savez jamais ce qui va devenir un mot réservé dans les futures versions de SGBD.
bobince

1
C'est très vrai! Une de nos applications serveur fonctionnait bien jusqu'à ce que nous appliquions une mise à niveau à notre moteur de base de données, qui ajoutait un nouveau mot-clé. Soudain, tout ce qui a interrogé une table particulière s'est cassé.
Miquella

@bobince Quand j'étais nouveau dans le développement, j'ai nommé une colonne rangeou quelque chose comme ça. Lorsque nous sommes passés à MySQL 5, cela a échoué parce que c'était un nouveau mot réservé!
alex

1
N'utilisez pas de guillemets doubles. Cela ne fonctionnera pas toujours. Par exemple ... DELETE FROM app_key_storesWHERE ("key" = 'c5cc4f30-31f3-0130-505e-14dae9da9fc5_range'); Requête OK, 0 ligne affectée (0,00 sec) SUPPRIMER DE O app_key_stores( key= 'c5cc4f30-31f3-0130-505e-14dae9da9fc5_range'); Requête OK, 5 lignes affectées (0,00 s)
Altonymous

44

Pour moi, il est très logique de les utiliser à tout moment lorsque vous traitez des noms de champs.

  • Premièrement, une fois que vous avez pris l'habitude, il ne fait pas de mal de simplement appuyer sur la touche backtick.
  • Deuxièmement, pour moi, il est plus facile de voir quels sont exactement les champs de votre requête et quels sont les mots clés ou les méthodes.
  • Enfin, il vous permet d'utiliser le nom de champ que vous souhaitez lors de la conception de votre table. Parfois, il est très judicieux de nommer un champ "clé", "ordre" ou "valeurs" ... qui nécessitent tous des accents inversés pour y faire référence.

19
Vous devez également ajouter qu'il vous protège de tout futur mot réservé utilisé (ce qui m'a mordu auparavant).
alex

5
En fait, quelqu'un a modifié une fois les backticks supplémentaires d'une de mes questions, ce qui m'a bouleversé, car c'est la raison exacte pour laquelle j'entoure chaque variable avec eux
Brian Leishman

2
Il permet également d'utiliser en toute sécurité des étiquettes non anglaises, ce qui suffit à lui seul à encourager l'utilisation de backticks.
Aternus

26

Les backticks ne font pas partie du SQL ANSI standard. Depuis le manuel mysql :

Si le mode SQL ANSI_QUOTES est activé, il est également possible de citer les identifiants entre guillemets

Donc, si vous utilisez des backticks et que vous décidez ensuite de vous éloigner de MySQL, vous avez un problème (bien que vous ayez probablement aussi des problèmes beaucoup plus importants)


9

Il n'y a rien de mal si vous continuez à utiliser MYSQL, sauf peut-être la flou visuelle des requêtes. Mais ils permettent l'utilisation de mots-clés réservés ou d'espaces incorporés comme noms de table et de colonne. Ceci est un non-non avec la plupart des moteurs de base de données et empêchera toute migration ultérieure.

Pour faciliter la lecture, de nombreuses personnes utilisent des majuscules pour les mots-clés SQL, par exemple.

SELECT some_fied, some_other_field FROM whatever WHERE id IS NULL;

6

Si vous me le demandez, les backticks doivent toujours être utilisés. Mais il y a certaines raisons pour lesquelles une équipe peut préférer ne pas les utiliser.

Avantages:

  • En les utilisant, il n'y a pas de mots réservés ni de caractères interdits.
  • Dans certains cas, vous obtenez des messages d'erreur plus descriptifs.
  • Si vous évitez les mauvaises pratiques, vous ne vous en souciez pas, mais ... en vrai, c'est parfois un moyen décent d'éviter les injections SQL.

Désavantages:

  • Ils ne sont pas standard et ne sont généralement pas portables. Cependant, tant que vous n'utilisez pas de backtick dans le cadre d'un identifiant (ce qui est la pire pratique que je puisse imaginer), vous pouvez porter votre requête en supprimant automatiquement les backticks.
  • Si certaines de vos requêtes proviennent d'Access, ils peuvent citer les noms de table avec "(et peut-être que vous ne pouvez pas supprimer tous les" aveuglément). Cependant, les mélanges de backticks et de guillemets doubles sont autorisés.
  • Certains logiciels ou fonctions stupides filtrent vos requêtes et ont des problèmes avec les backticks. Cependant, ils font partie de l'ASCII, ce qui signifie que votre logiciel / fonction est très mauvais.

9
Utiliser des backticks n'a absolument rien à voir avec le fait d'éviter les injections SQL.
Andy Lester

6
@andy cela pourrait aider, car un attaquant doit le fermer avec un autre backtick pour injecter. Cela fait peu, mais c'est toujours quelque chose
jasonszhao

4

Il est beaucoup plus facile de rechercher dans votre base de code quelque chose dans les backticks. Disons que vous avez une table nommée event. grep -r "event" *peut renvoyer des centaines de résultats. grep -r "\`event\`" *renverra tout ce qui fait probablement référence à votre base de données.


En général, ce n'est pas vraiment un avantage. Les tables que l'on rencontre professionnellement s'appellent plus comme new_users_info que "general".
ankush981

3

Eh bien, pour autant que je sache, tout le but de l'utilisation des backticks est de vous permettre d'utiliser des noms qui coïncident avec des mots-clés réservés. Donc, si le nom n'entre pas en collision avec un mot-clé réservé, je ne vois aucune raison d'utiliser des backticks. Mais ce n'est pas non plus une raison de les interdire.


2

Simple chose à propos backtick `` est utilisé pour désignent identifiant comme bdd, nom_table etc, et guillemet simple « » , guillemet « » pour les littéraux de chaîne, alors que « » l' utilisation de la valeur d'impression telle qu'elle est et « » imprimer la cale variable de valeur ou dans un autre cas, imprimez le texte qu'il a.

i.e 1.-> use `model`;   
    here `model` is database name not conflict with reserve keyword 'model'
2- $age = 27;
insert into `tbl_people`(`name`,`age`,`address`) values ('Ashoka','$age',"Delhi");

here i used both quote for all type of requirement. If anything not clear let me know..

0

si vous utilisez certains noms de champs comme valeurs par défaut mysql ou mssql, par exemple "status", vous devez utiliser des backticks ("select statusfrom table_name" ou "select id from table_name where status= 1"). car mysql renvoie des erreurs ou ne fonctionne pas la requête.


0

L'utilisation principale des backticks (`) en SQL est de les utiliser dans des situations où vous allez les appeler à nouveau dans les clauses à venir. À chaque autre fois, il est recommandé d'utiliser des guillemets doubles ("").

Par exemple

SELECT CONCAT(Name, ' in ', city, ', ', statecode) AS `Publisher and Location`,
    COUNT(ISBN) AS "# Books",
    MAX(LENGTH(title)) AS "Longest Title",
    MIN(LENGTH(title)) AS "Shortest Title"
FROM Publisher JOIN Book
ON Publisher.PublisherID = Book.PublisherID WHERE INSTR(name, 'read')>0
GROUP BY `Publisher and Location`
HAVING COUNT(ISBN) > 1;

Dans l'instruction ci-dessus, voyez-vous comment Publisher and Locationest utilisé à nouveau dans la GROUP BYclause.

À la place d'utiliser

GROUP BY Nom, ville, code d'état

Je viens d'utiliser

PAR GROUPE Publisher and Location

Ce n'est que lorsque de telles situations se présentent, qu'il est utile d'utiliser des backticks. Dans tous les autres cas, l'utilisation de guillemets doubles est recommandée.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.