Usando backticks em torno dos nomes dos campos

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

Isso é:

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

O uso de backticks permite que você use caracteres alternativos. Na escrita de consultas, esse não é um problema, mas se alguém assumir que você pode usar backticks, eu assumiria que ele permite que você se safe de 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á marcações de retorno e marcas de nomes de tabela totalmente qualificados. Portanto, se você estiver usando recursos de geração de consulta e reescrita automática de consultas, os backticks tornariam menos confuso a análise de seu código.

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

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ê precisar portar seu SQL para outro banco de dados, use aspas duplas.

Para mim, faz muito sentido usá-los o tempo todo ao lidar com nomes de campos.

• Em primeiro lugar, uma vez que você adquira o hábito, não dói apenas pressionar a tecla backtick.
• Em segundo lugar, para mim, fica mais fácil ver quais são exatamente os campos na sua consulta e quais são as palavras-chave ou métodos.
• Por fim, permite que você use qualquer nome de campo que desejar ao projetar sua tabela. Às vezes, faz muito sentido nomear um campo como "chave", "ordem" ou "valores" ... todos os quais exigem reticências ao se referir a eles.

Os backticks não fazem parte do SQL ANSI padrão. A partir do manual do mysql :

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

Portanto, se você usa backticks e decide se afastar do MySQL, você tem um problema (embora provavelmente também tenha problemas muito maiores)

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

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;

Se você me perguntar, sempre devem ser usados ​​retalhos. 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 mensagens de erro mais descritivas.
• Se você evitar más práticas, não se importa, mas ... em palavras reais, às vezes elas são uma maneira decente de evitar injeções de SQL.

Desvantagens:

• 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 posso imaginar), você pode portar sua consulta removendo automaticamente os backticks.
• Se algumas das suas consultas vierem do Access, elas podem citar os nomes das 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úpido filtra suas consultas e tem problemas com backticks. No entanto, eles fazem parte do ASCII, portanto, isso significa que seu software / função é muito ruim.

É muito mais fácil pesquisar na sua base de códigos por algo nos 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 faça referência ao seu banco de dados.

Bem, até onde eu sei, todo o objetivo de usar backticks é para que você possa usar nomes que coincidam com palavras-chave reservadas. Portanto, se o nome não estiver colidindo com uma palavra-chave reservada, não vejo motivo para usar backticks. Mas isso também não é motivo para bani-los.

Coisa simples sobre backtick `` é usada para denotar identificador como database_name, table_name etc e aspas simples '' , aspas duplas "" para literais de string, enquanto "" use para print value como está e '' imprime a variável value hold ou em outro caso, imprima o texto que ele 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..

se você estiver usando alguns nomes de campos como valores padrão do mysql ou mssql, por exemplo "status", precisará usar backticks ("selecione statusdo nome da tabela" ou "selecione o ID do nome da tabela onde status= 1"). porque o mysql retorna erros ou não funciona na consulta.

O principal uso de backticks (`) no SQL é usá-los em situações em que você os chamará novamente nas próximas cláusulas. Em todos os outros momentos, é recomendável usar aspas duplas ("").

Por exemplo

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;

Na declaração acima, você vê como Publisher and Locationé usado novamente emGROUP BY cláusula.

Ao invés de usar

GRUPO POR Nome, cidade, código de estado

Eu apenas usei

GRUPO POR Publisher and Location

Somente quando tais situações surgem, é útil usar backticks. Em todos os outros momentos, é recomendável usar aspas duplas.