Después de leer un par de respuestas y comentarios sobre algunas preguntas de SQL aquí, y también de escuchar que un amigo mío trabaja en un lugar que tiene una política que las prohíbe, me pregunto si hay algo malo en usar backticks alrededor de los nombres de campo en MySQL .
Es decir:
SELECT `id`, `name`, `anotherfield` ...
-- vs --
SELECT id, name, anotherfield ...El uso de backticks le permite usar caracteres alternativos. En la redacción de consultas no es un problema, pero si se supone que puede usar backticks, supongo que le permite salirse con la suya con cosas ridículas como
SELECT `id`, `my name`, `another field` , `field,with,comma` Lo que, por supuesto, genera tablas mal nombradas.
Si solo está siendo conciso, no veo un problema, notará si ejecuta su consulta como tal
EXPLAIN EXTENDED Select foo,bar,baz La advertencia generada que vuelve tendrá tics de retroceso y nombres de tabla totalmente calificados. Por lo tanto, si está utilizando funciones de generación de consultas y una reescritura automática de consultas, los backticks harán que cualquier cosa que analice su código sea menos confusa.
Sin embargo, creo que, en lugar de exigir si puedes usar backticks, deberían tener un estándar para los nombres. Soluciona más problemas 'reales'.
select count from foovs select "count" from foodará resultados muy diferentes. Pero postgres difiere de mysql en 2 formas: 1. Los campos se citan por "". 2. Los campos sin comillas no distinguen entre mayúsculas y minúsculas postgresql.org/docs/current/static/…
El único problema con los backticks es que no son compatibles con ANSI-SQL, por ejemplo, no funcionan en SQL Server.
Si existe la posibilidad de que tenga que portar su SQL a otra base de datos, utilice comillas dobles.
rangeo algo así. ¡Cuando actualizamos a MySQL 5 falló porque era una nueva palabra reservada!
app_key_storesWHERE ("key" = 'c5cc4f30-31f3-0130-505e-14dae9da9fc5_range'); Consulta OK, 0 filas afectadas (0.00 seg) BORRAR DE app_key_storesDONDE ( key= 'c5cc4f30-31f3-0130-505e-14dae9da9fc5_range'); Consulta OK, 5 filas afectadas (0.00 seg)
Para mí tiene mucho sentido usarlos en todo momento cuando se trata de nombres de campo.
Los backticks no son parte del ANSI SQL estándar. Del manual de mysql :
Si el modo ANSI_QUOTES SQL está habilitado, también se permite citar identificadores dentro de comillas dobles
Entonces, si usa backticks y luego decide alejarse de MySQL, tiene un problema (aunque probablemente también tenga problemas mucho más grandes)
No hay nada de malo si sigues usando MYSQL, excepto tal vez la confusión 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;Si me preguntas, los backticks siempre deben usarse. Pero hay algunas razones por las que un equipo puede preferir no usarlas.
Ventajas:
Desventajas
Es mucho más fácil buscar en su base de código algo en backticks. Digamos que tienes una tabla llamada event. grep -r "event" *podría devolver cientos de resultados. grep -r "\`event\`" *devolverá cualquier cosa que probablemente haga referencia a su base de datos.
Bueno, hasta donde yo sé, el propósito de usar backticks es para que puedas usar nombres que coincidan con palabras clave reservadas. Entonces, si el nombre no está chocando con una palabra clave reservada, no veo ninguna razón para usar backticks. Pero, esa tampoco es razón para prohibirlos.
Cosa simple sobre la tecla de retroceso `` es usar para denotar identificador como nombre_base_datos, nombre_tabla, etc., y comilla simple '' , comilla doble "" para literales de cadena, mientras que "" se usa para imprimir el valor tal como está y '' imprimir la variable de valor retener o en otro caso imprime 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..si está utilizando algunos nombres de campo como valores predeterminados de mysql o mssql, por ejemplo, "estado", debe usar las marcas de retroceso ("select statusfrom table_name" o "select id from table_name where status= 1"). porque mysql devuelve errores o no funciona la consulta.
El uso principal de backticks (`) en SQL es usarlos en situaciones en las que va a volver a llamarlos en próximas cláusulas. En cualquier otro momento, se recomienda utilizar comillas dobles ("").
Por ejemplo
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;En la declaración anterior, ¿cómo Publisher and Locationse usa nuevamente en la GROUP BYcláusula?
En lugar de usar
GROUP BY Nombre, ciudad, código de estado
Acabo de usar
AGRUPAR POR
Publisher and Location
Solo cuando surgen tales situaciones, es útil usar backticks. En todos los demás tiempos se recomienda el uso de comillas dobles.
count,type,tableo similarescount,type, ytable. Esos son términos terriblemente ambiguos y en casi todos los casos esos nombres podrían mejorarse para ser más específicos. Nombrar las columnas de ese tipo también es peligroso y una fuente potencial de errores, ya que nunca se sabe cuándo alguien podría olvidar agregar los backticks o no darse cuenta de que tienen que hacerlo. Creo que es mejor evitar usar términos reservados como nombres de columna.