Usando backsicks em torno de nomes de campo

Question

Depois de ler algumas respostas e comentários sobre algumas perguntas do SQL aqui, e também ouvir que um amigo meu trabalha em um local que tem uma política que lhes proíbe, estou me perguntando se há algo errado em usar backticks em torno de nomes de campo em MySQL .

Aquilo é:

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

Answer 1

O uso de backsticks permite que você use caracteres alternativos. Na escrita de consulta, não é um problema, mas se alguém assume que você pode simplesmente usar backticks, eu suponho que permite que você se distaça 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 um problema com isso, observará se você executar sua consulta como tal

EXPLAIN EXTENDED Select foo,bar,baz 

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

Acho que, no entanto, em vez de exigir se você pode ou não usar backticks, eles devem ter um padrão para nomes. Ele resolve mais problemas 'reais'.

Answer 2

O único problema com os backsticks é 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 cotações duplas.

Answer 3

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

• Em primeiro lugar, depois de entrar no hábito, não dói apenas acertar a chave de backtick.
• Em segundo lugar, para mim, facilita a ver quais são exatamente os campos em 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 "chave", "ordem" ou "valores" ... todos exigem backticks ao se referir a eles.

Answer 4

Backticks não fazem parte do ANSI SQL padrão. A partir de o manual do MySQL:

Se o modo ANSI_QUTES SQL estiver ativado, também será permitido citar identificadores dentro de cotações duplas

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

Answer 5

Não há nada de errado se você continuar usando o MySQL, exceto talvez a fuzineira visual das consultas. Mas eles permitem o uso de palavras -chave reservadas ou espaços incorporados como nomes de tabela e colunas. Este é 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 caps para palavras -chave SQL, por exemplo.

SELECT some_fied, some_other_field FROM whatever WHERE id IS NULL;

Answer 6

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

Vantagens:

• Usando -os, não há palavras reservadas ou chares proibidos.
• Em alguns casos, você obtém mensagens de erro mais descritivas.
• Se você evita práticas ruins que não se importa, mas ... na palavra real, à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 eu sou capaz de imaginar), você pode portar sua consulta removendo automaticamente os backticks.
• Se algumas das suas consultas vieram do acesso, eles podem citar nomes de tabela com "(e talvez você não possa remover todos os" cegamente). No entanto, são permitidas misturas de backsticks e citações duplas.
• Algum software estúpido ou função filtra suas consultas e tem problemas com backticks. No entanto, eles fazem parte do ASCII, então isso significa que seu software/função é muito ruim.

Answer 7

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

Answer 8

É muito mais fácil pesquisar na sua base de código em busca de backsticks. Diga que você tem uma mesa chamada event. grep -r "event" * pode retornar centenas de resultados. grep -r "\`event\`" * retornará qualquer coisa provavelmente referenciando seu banco de dados.

Answer 9

Coisa simples em backtick `` é usado para denotar identificador como database_name, table_name etc e citação única '', citação dupla "" Para literais de string, enquanto "" use o valor de impressão como é e '' imprima a variável de valor Hold ou, em outro caso, imprima o texto que ele tem.

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

Answer 10

Se você estiver usando alguns nomes de campo como padrão MySQL ou MSSQL, por exemplo, "Status", você deve usar backticks ("Selecionar status de table_name "ou" Selecione ID de Table_name onde status= 1 "). Porque o MySQL retorna erros ou não funciona a consulta.

Answer 11

O principal uso de backsticks (`) no SQL é usá -los em situações em que você os chamará novamente nas próximas cláusulas. Em todas as outras vezes, é recomendável usar citações 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 em GROUP BY cláusula.

Ao invés de usar

Grupo por nome, City, Statecode

Eu apenas usei

Grupo por Publisher and Location

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