Usar palos de atrás alrededor de los nombres de los campos

Después de leer un par de respuestas y comentarios sobre algunas preguntas SQL aquí, y también escuchar que un amigo mío trabaja en un lugar que tiene una política que las prohíbe, me pregunto si hay algo de malo con el uso de marcadores en los nombres de campo en MySQL .

Es decir:

SELECT `id`, `name`, `anotherfield` ...
-- vs --
SELECT id, name, anotherfield ...
0
ver también MySQL "> stackoverflow.com/questions/23446377/…
agregado el autor Ian Ringrose, fuente
Los backticks son realmente útiles si quiere tener nombres de columna como count , type , table o similar
agregado el autor knittl, fuente

10 Respuestas

Bueno, hasta donde yo sé, el propósito del uso de backticks es para que puedas usar nombres que coincidan con las palabras clave reservadas. Entonces, si el nombre no está colisionando con una palabra clave reservada, no veo ninguna razón para usar respaldos. Pero eso tampoco es motivo para prohibirlos.

0
agregado

Para mí tiene mucho sentido usarlos en todo momento cuando se trata de nombres de campos.

  • En primer lugar, una vez que te acostumbras, no hace daño simplemente presionar la tecla de retroceso.
  • En segundo lugar, para mí, es más fácil ver qué son exactamente los campos en su consulta, y cuáles son las palabras clave o los métodos.
  • Por último, le permite usar cualquier nombre de campo que desee al diseñar su tabla. A veces tiene mucho sentido nombrar un campo "clave", "orden" o "valores" ... todos los cuales requieren retrocesos al referirse a ellos.
0
agregado
También debe agregar que lo protege de cualquier palabra reservada en el futuro que se utilice (lo cual me ha mordido antes).
agregado el autor alex, fuente
De hecho, alguien editó los backticks extra de una de mis preguntas una vez, lo que me molestó, ya que esta es la razón exacta por la que rodeo cada variable con ellos.
agregado el autor Brian Leishman, fuente
También permite el uso seguro de etiquetas que no sean en inglés, lo cual es suficiente para fomentar el uso de marcadores.
agregado el autor Aternus, fuente

El uso de palos de retroceso le permite usar caracteres alternativos. En la escritura de consultas, no es un problema, pero si uno supone que puede usar los trazos, supongo que le permite salirse con cosas ridículas como

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

Lo cual, por supuesto, genera tablas mal nombradas.

Si solo estás siendo conciso, no veo ningún problema con eso, notarás si ejecutas tu consulta como tal

EXPLAIN EXTENDED Select foo,bar,baz 

La advertencia generada que se devuelve tendrá nombres de tabla totalmente calificados y . Por lo tanto, si usa funciones de generación de consultas y vuelve a escribir automáticamente las consultas, los backticks harían que cualquier información para analizar su código sea menos confusa.

Sin embargo, creo que, en lugar de ordenar si se pueden usar o no los backticks, deberían tener un estándar para los nombres. Resuelve más problemas "reales".

0
agregado
¿Necesitamos usarlos en PostgreSQL también?
agregado el autor Yousuf Memon, fuente
No hay necesidad, solo recomendación. Es útil representarlos entre comillas para evitar la ambigüedad con las palabras clave de SQL si en el futuro se agrega una palabra clave SQL que comparta el nombre de su campo. El único momento en que necesita/cita/cita es cuando un campo lo hace comparte un nombre de palabra clave, por ejemplo, selecciona conteo de foo contra selecciona "conteo" de foo dará resultados muy diferentes. Pero postgres difiere de MySQL de 2 maneras: 1. Los campos son citados por "" . 2. Los campos sin comillas no distin
agregado el autor Kent Fredric, fuente

Backticks no son parte de ANSI SQL estándar. De el manual de MySQL :

Si el modo SQL ANSI_QUOTES es   habilitado, también está permitido citar   identificadores entre comillas dobles

Entonces, si usas los trazos inversos y luego decides alejarte de MySQL, tienes un problema (aunque es probable que tengas problemas mucho más grandes también)

0
agregado

El único problema con los backticks es que no cumplen con ANSI-SQL, p. no funcionan en SQL Server.

Si existe la posibilidad de que deba transferir su SQL a otra base de datos, use comillas dobles.

0
agregado
@bobince Cuando estaba nuevo en el programa de desarrollo, denominé una columna rango o algo así. Cuando actualizamos a MySQL 5, ¡falló porque era una nueva palabra reservada!
agregado el autor alex, fuente
No use comillas dobles No siempre funcionará. Por ejemplo ... ELIMINAR DE app_key_stores WHERE ("clave" = 'c5cc4f30-31f3-0130-505e-14dae9da9fc5_range'); Consulta OK, 0 filas afectadas (0.00 segundos) ELIMINAR DE app_key_stores WHERE (clave = 'c5cc4f30-31f3-0130-505e-14dae9da9fc5_range'); Consulta OK, 5 filas afectadas (0.00 seg)
agregado el autor Altonymous, fuente
Sí. Utilice el modo ANSI de MySQL - dev.mysql.com/doc /refman/5.0/en/server-sql-mode.html - para habilitar comillas dobles en MySQL y así recuperar la compatibilidad entre bases de datos. Backticks/quotes también son necesarios porque nunca se sabe qué se va a convertir en una palabra reservada en futuras versiones de DBMS.
agregado el autor bobince, fuente
¡Eso es muy cierto! Una de nuestras aplicaciones de servidor funcionaba correctamente hasta que aplicamos una actualización a nuestro motor de base de datos, que agregó una nueva palabra clave. De repente, todo lo que cuestionaba una mesa en particular se rompió.
agregado el autor Miquella, fuente

No hay nada de malo si sigues usando MYSQL, excepto tal vez la fuzziness visual de las consultas. Pero sí permiten el uso de palabras clave reservadas o espacios incrustados como nombres de tabla y columna. Este es un no-no con la mayoría de los motores de bases de datos y evitará cualquier migración en un momento posterior.

En cuanto a la lectura fácil, muchas personas usan mayúsculas para las palabras clave SQL, por ejemplo.

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

Es mucho más fácil buscar en su base de código algo en los apoyos. Supongamos que tiene una tabla llamada event . grep -r "event" * puede devolver cientos de resultados. grep -r "\` event \ `" * devolverá cualquier cosa que probablemente haga referencia a su base de datos.

0
agregado
En general, no es realmente un beneficio. Las tablas con las que uno se encuentra profesionalmente se denominan más como new_users_info que "general".
agregado el autor dotslash, fuente

Si me preguntas, los backticks siempre deben usarse. Pero hay algunas razones por las que un equipo puede preferir no usarlas.

Ventajas:

  • Utilizándolos, no hay palabras reservadas ni caracteres prohibidos.
  • En algunos casos, obtienes mensajes de error más descriptivos.
  • Si evita las malas prácticas, no le importa, pero ... en términos reales, a veces son una forma decente de evitar las inyecciones de SQL.

DisVentajas:

  • No son estándar y generalmente no son portátiles. Sin embargo, siempre que no uses un backtick como parte de un identificador (que es la peor práctica que puedo imaginar), puedes portar tu consulta eliminando automáticamente los backticks.
  • Si parte de su consulta proviene de Access, pueden citar nombres de tabla con "(y quizás no pueda eliminar todo" a ciegas). Sin embargo, se permiten mezclas de marcadores y dobles comillas.
  • Algún software o función estúpida filtra tus consultas y tiene problemas con los backticks. Sin embargo, son parte de ASCII, lo que significa que su software/función es muy mala.
0
agregado
@andy might help, ya que un atacante tiene que cerrarlo con otro backtick para inyectar. Hace poco, pero eso todavía es algo
agregado el autor jasonszhao, fuente
El uso de "backticks" no tiene absolutamente nada que ver con evitar las inyecciones de SQL.
agregado el autor Andy Lester, fuente

Si está utilizando algunos nombres de campo como valores predeterminados de MySQL o mssql, por ejemplo, "estado", debe usar los respaldos ("seleccionar estado de table_name" o "seleccionar id de table_name donde status = 1 "). porque MySQL devuelve errores o no funciona la consulta.

0
agregado

Lo simple sobre el backtick `` se usa para denotar identificador como nombre_base_datos, nombre_tabla, etc., y comillas simples '' , comillas dobles "" para cadenas literales, mientras que "" se usa para imprimir el valor tal como está y "imprimir la variable de valor mantener o en otro caso imprimir el texto que tiene.

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
agregado
Ahora está bien, mira con cuidado ...
agregado el autor Sonpal singh Sengar, fuente