Utilisation des accents à la suite des noms de champs

Question

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

C'est:

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

Answer 1

L'utilisation de guillemets permet d'utiliser d'autres caractères. En écrivant requête ce n'est pas un problème, mais si l'on suppose que vous pouvez simplement utiliser des accents graves, je suppose qu'il vous permet de sortir avec des choses ridicules comme

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

Ce qui fait bien sûr de générer des tableaux mal nommés.

Si vous êtes juste d'être concis, je ne vois pas de problème avec elle, 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 back- coche et noms de table complets. Donc, si vous utilisez des fonctionnalités de génération de requêtes et une réécriture automatique des requêtes, les backticks rendraient toute l'analyse de votre code moins confuse.

Je pense cependant, au lieu d'exiger si vous pouvez utiliser des guillemets, ils devraient avoir un standard pour les noms. Il résout plus de problèmes «réels». Les backticks ne font pas partie de la norme ANSI SQL.

Answer 2

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

Answer 3

Pour moi, il est logique de les utiliser en tout temps pour traiter les noms de champs.

• Tout d'abord, une fois que vous prenez l'habitude, il ne fait pas de mal à frapper simplement la touche de retour.
• 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 logique de nommer un champ "clé", "ordre", ou "valeurs" ... ce qui nécessite des backticks quand on s'y réfère.

Answer 4

Le seul problème avec les guillemets est qu'ils ne sont pas conformes à ANSI-SQL, par ex. ils ne fonctionnent pas dans SQL Server.

Si vous devez transférer votre code SQL vers une autre base de données, utilisez des guillemets.

Answer 5

De the mysql manual:

Si le mode ANSI_QUOTES SQL est activé, il est permis de citer identificateurs entre guillemets

Donc, si vous utilisez des accents graves et décider ensuite de se déplacer loin de MySQL, vous vous avez un problème (bien que vous ayez probablement aussi beaucoup plus de problèmes)

Answer 6

Il n'y a rien de mal si vous continuez à utiliser MYSQL, sauf peut-être le caractère visuel des requêtes. Mais ils permettent l'utilisation de mots-clés réservés ou d'espaces incorporés comme noms de tables et de colonnes. Ceci est un non-non avec la plupart des moteurs de base de données et empêchera toute migration ultérieure. Comme 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; 

Answer 7

Il est beaucoup plus facile de rechercher votre code-base pour quelque chose dans les backticks. Supposons que vous avez une table nommée event. grep -r "event" * peut renvoyer des centaines de résultats. grep -r "\`event\`" * retournera quelque chose référençant probablement votre base de données.

Answer 8

Si vous me le demandez, les guêtres doivent toujours être utilisées. 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 ou caractères interdits réservés.
• Dans certains cas, vous obtenez plus de messages d'erreur descriptifs.
• Si vous évitez les mauvaises pratiques, cela ne vous dérange pas, mais ... en réalité, elles sont parfois un bon moyen d'éviter les injections SQL.

Inconvénients:

• Ils ne sont pas standard et généralement pas portable. Cependant, tant que vous n'utilisez pas un 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 des noms de tables avec "(et peut-être vous ne pouvez pas supprimer tous les" aveuglément "). Cependant, les mélanges de backticks et de doubles quotes sont autorisés.
• Certains logiciels ou fonctions stupides filtrent vos requêtes et ont des problèmes avec les guillemets. Cependant, ils font partie de l'ASCII, ce qui signifie que votre logiciel/fonction est très mauvais.

Answer 9

si vous utilisez des noms de champs comme valeurs par défaut de MySQL ou MSSQL par exemple "statut", vous devez utiliser des accents graves ("select status from nom_table" ou "select id de table_name où status = 1"). car mysql renvoie des erreurs ou ne fonctionne pas la requête.

Answer 10

chose simple à propos backtick `` est utilisé pour identifier désignent comme bdd, nom_table etc, et guillemet simple « », guillemet « » pour les littéraux de chaîne, alors que « » utiliser la valeur d'impression comme est et '' imprime la valeur variable hold ou dans un autre cas imprime le texte qu'il possède.

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..