mysql - languages - Usar palos de atrás alrededor de los nombres de los campos

mysql password reserved word

Question

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

Answer 1

Backticks no son parte de ANSI SQL estándar. Del manual de mysql :

Si el modo SQL ANSI_QUOTES está habilitado, también se permite 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)

Answer 2

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.

Answer 3

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

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

Answer 4

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 él, notarás si ejecutas tu consulta como tal

EXPLAIN EXTENDED Select foo,bar,baz

La advertencia generada que se devuelve tendrá retrocesos y nombres de tablas completamente calificados. 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".

Answer 5

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.

Answer 6

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;

Answer 7

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.

Answer 8

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.

Desventajas:

• 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 tal vez no pueda eliminar todo" a ciegas). Sin embargo, se permiten mezclas de backticks y comillas dobles.
• Algún software o función estúpida filtra tus consultas, y tiene problemas con los backticks. Sin embargo, son parte de ASCII por lo que esto significa que su software / función es muy mala.

Answer 9

Simple thing about backtick `` es uso para denotar identificador como nombre_base_datos, nombre_tabla etc, y comillas simples '''' , comillas dobles '''' para literales de cadenas, mientras que '''' utilizar para imprimir valor tal como es e '''' imprimir la variable de valor mantener o en otro caso, imprima 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..

Answer 10

si está utilizando algunos nombres de campo como valores predeterminados de mysql o mssql, por ejemplo, "estado", debe utilizar los respaldos ("seleccionar el status de table_name" o "select id from table_name where status = 1"). porque mysql devuelve errores o no funciona la consulta.