Usando backticks em torno de nomes de campo

Depois de ler algumas respostas e comentários em algumas questões SQL aqui, e também ouvir que um amigo meu trabalha em um lugar que tem uma política que os proíbe, estou imaginando se há algo errado em usar backticks em nomes de campos no MySQL .

Isso é:

SELECT `id`, `name`, `anotherfield` ...
-- vs --
SELECT id, name, anotherfield ...
0
veja também MySQL "> stackoverflow.com/questions/23446377/…
adicionado o autor Ian Ringrose, fonte
backticks são realmente úteis se você quiser ter nomes de coluna como count , tipo , table ou similar
adicionado o autor knittl, fonte

10 Respostas

Bem, tanto quanto eu sei, todo o propósito de usar backticks é para que você possa usar nomes que coincidam com palavras-chave reservadas. Então, se o nome não estiver colidindo com uma palavra reservada, não vejo nenhum motivo para usar backticks. Mas também não é motivo para bani-los.

0
adicionado

Para mim, faz muito sentido usá-los em todos os momentos ao lidar com nomes de campo.

  • Primeiramente, quando você adquire o hábito, não faz mal apenas apertar a tecla de backtick.
  • Em segundo lugar, para mim, fica mais fácil ver quais são exatamente os campos da sua consulta e quais são palavras-chave ou métodos.
  • Por fim, permite que você use o nome do campo que desejar ao criar sua tabela. Às vezes faz muito sentido nomear um campo "chave", "ordem" ou "valores" ... todos os quais requerem backticks quando se referem a eles.
0
adicionado
Você também deve acrescentar que ele protege você de quaisquer palavras reservadas futuras que estejam sendo usadas (o que me mordeu antes).
adicionado o autor alex, fonte
Na verdade, eu fiz alguém editar os backstacks extras de uma das minhas perguntas uma vez, o que me chateou, já que essa é a razão exata pela qual eu envolvo cada variável com eles
adicionado o autor Brian Leishman, fonte
Também permite o uso seguro de rótulos não ingleses, o que por si só é suficiente para incentivar o uso de backticks.
adicionado o autor Aternus, fonte

Usando backticks permite que você use caracteres alternativos. Na escrita de consultas, não é um problema tão grande, mas se você assumir que pode usar apenas backticks, eu diria que isso permite que você se dê bem com coisas ridículas como

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

O que, claro, gera tabelas mal nomeadas.

Se você está apenas sendo conciso, não vejo problema com isso, você notará se executar sua consulta como tal

EXPLAIN EXTENDED Select foo,bar,baz 

O aviso gerado que voltará terá back-ticks e nomes de tabelas totalmente qualificados. Portanto, se você estiver usando recursos de geração de consulta e reescrita automatizada de consultas, os backticks farão com que qualquer coisa que analise seu código seja menos confusa.

No entanto, acho que, em vez de determinar se você pode ou não usar backticks, eles devem ter um padrão para nomes. Isso resolve mais problemas "reais".

0
adicionado
Precisamos usá-los no PostgreSQL também?
adicionado o autor Yousuf Memon, fonte
Não há necessidade, apenas recomendação. É útil representá-los para evitar ambigüidade com palavras-chave SQL se, no futuro, for adicionada uma palavra-chave SQL que compartilhe o nome de seus campos. A única vez que você/precisa/para citar é quando um campo faz compartilhar um nome de palavra-chave, por exemplo, seleciona contagem de foo vs seleciona "count" de foo dará resultados muito diferentes. Mas o postgres difere do MySQL de 2 maneiras: 1. Os campos são citados por "" . 2. Os campos sem aspas são insensíveis a maiúsculas e minúsculas
adicionado o autor Kent Fredric, fonte

Backticks não fazem parte do padrão ANSI SQL. De o manual do MySQL :

Se o modo SQL ANSI_QUOTES for   ativado, também é permitido citar   identificadores entre aspas duplas

Então, se você usa backticks e então decide se afastar do MySQL, você tem um problema (embora você provavelmente tenha problemas bem maiores)

0
adicionado

O único problema com backticks é que eles não são compatíveis com ANSI-SQL, por exemplo. eles não funcionam no SQL Server.

Se houver uma chance de você ter que portar seu SQL para outro banco de dados, use aspas duplas.

0
adicionado
@bobince Quando eu era novo para dev, nomeei uma coluna range ou algo parecido. Quando atualizamos para o MySQL 5 ele falhou porque era uma nova palavra reservada!
adicionado o autor alex, fonte
Não use aspas duplas. Nem sempre funcionará. Por exemplo ... DELETE FROM app_key_stores WHERE ("chave" = 'c5cc4f30-31f3-0130-505e-14dae9da9fc5_range'); Consulta OK, 0 linhas afetadas (0.00 seg) DELETE FROM app_key_stores WHERE (tecla = 'c5cc4f30-31f3-0130-505e-14dae9da9fc5_range'); Consulta OK, 5 filas afetadas (0,00 s)
adicionado o autor Altonymous, fonte
Sim. Use o modo ANSI do MySQL - dev.mysql.com/doc /refman/5.0/en/server-sql-mode.html - para ativar aspas duplas no MySQL e, assim, recuperar a compatibilidade entre bancos de dados. Backticks/aspas também são necessárias porque você nunca sabe o que vai se tornar uma palavra reservada em futuras versões do DBMS.
adicionado o autor bobince, fonte
Isto é uma grande verdade! Um de nossos aplicativos de servidor estava funcionando bem até que aplicamos uma atualização ao nosso mecanismo de banco de dados, que adicionou uma nova palavra-chave. De repente, tudo o que questionou uma determinada mesa foi quebrado.
adicionado o autor Miquella, fonte

Não há nada de errado se você continuar usando o MYSQL, exceto talvez a perceptibilidade visual das consultas. Mas eles permitem o uso de palavras-chave reservadas ou espaços incorporados como nomes de tabelas e colunas. Este é um não-não com a maioria dos mecanismos de banco de dados e impedirá qualquer migração em um momento posterior.

Quanto à leitura fácil, muitas pessoas usam limites para palavras-chave SQL, por exemplo.

SELECT some_fied, some_other_field FROM whatever WHERE id IS NULL;
0
adicionado

É muito mais fácil pesquisar sua base de código para algo em backticks. Digamos que você tenha uma tabela chamada event . grep -r "event" * pode retornar centenas de resultados. grep -r "\" event \ `" * retornará qualquer coisa que provavelmente referencie seu banco de dados.

0
adicionado
Em geral, não é realmente um benefício. As tabelas que se encontram profissionalmente são nomeadas mais como new_users_info do que "general".
adicionado o autor dotslash, fonte

Se você me perguntar, os backticks devem sempre ser usados. Mas existem algumas razões pelas quais uma equipe pode preferir não usá-las.

Vantagens:

  • Usando-os, não há palavras reservadas ou caracteres proibidos.
  • Em alguns casos, você recebe mais mensagens de erro descritivas.
  • Se você evitar práticas ruins, não se importa, mas ... na verdade, às vezes elas são uma maneira decente de evitar injeções de SQL.

DisVantagens:

  • Eles não são padrão e geralmente não são portáteis. No entanto, desde que você não use um backtick como parte de um identificador (que é a pior prática que eu possa imaginar), você pode transportar sua consulta removendo automaticamente os backticks.
  • Se algumas de suas consultas vierem do Access, elas podem citar nomes de tabelas com "(e talvez você não possa remover todas as" cegamente). No entanto, misturas de backticks e aspas duplas são permitidas.
  • Algum software ou função estúpida filtra suas consultas e tem problemas com os backticks. No entanto, eles fazem parte do ASCII, o que significa que o seu software/função é muito ruim.
0
adicionado
@andy it pode ajudar, já que um invasor precisa fechá-lo com outro backtick para injetar. Faz pouco, mas isso ainda é algo
adicionado o autor jasonszhao, fonte
Usar backticks não tem absolutamente nada a ver com evitar injeções de SQL.
adicionado o autor Andy Lester, fonte

Se você estiver usando alguns nomes de campos como valores padrão MySQL ou mssql por exemplo "status", você deve usar backticks ("selecionar status de table_name" ou "selecionar id de table_name onde status = 1 "). porque o MySQL retorna erros ou não trabalha a consulta.

0
adicionado

Coisa simples sobre backtick `` é usada para denotar identificador como database_name, table_name etc e aspas simples '' , aspas duplas "" para string literais, enquanto "" use para imprimir o valor como ele é e "imprima a variável de valor em espera ou em outro caso imprima o texto que possui.

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
adicionado
Agora está tudo bem, por favor, veja com cuidado ..
adicionado o autor Sonpal singh Sengar, fonte