SQL se ha estandarizado desde 1987 y se mantiene como ISO/IEC 9075, aunque cada motor agrega su propio dialecto en la parte superior, razón por la cual un formateador tiene que analizar en lugar de coincidir patrones.
La peor consulta que tuve que revisar fue 340 líneas en un solo pensamiento lógico: un informe de ingresos para un SaaS de Laravel, escrito como uno DB::select() Cuerda sin procesar, construida durante ocho meses por tres desarrolladores, cada uno de los cuales tenía una idea diferente sobre las capitalizaciones y ninguna sobre saltos de línea. En algún lugar de esa pared de texto, un LEFT JOIN se había convertido en silencio en un INNER JOIN durante una refactorización, y los clientes sin pedidos desaparecieron del informe. El error fue una palabra. Encontrarlo tomó un día y medio, no porque la lógica fuera difícil, sino porque la consulta lo era ilegible, y el código ilegible oculta sus errores a la vista.
Aquí está la cosa sobre SQL: a la base de datos no le importa su formato. El analizador lee select id,name from users where active=1 y SELECT id, name FROM users WHERE active = 1 como la misma declaración, produce el mismo plan de ejecución, devuelve las mismas filas al mismo tiempo. Formatear SQL es puramente para humanos, razón por la cual vale la pena hacerlo, porque los humanos son quienes lo revisan, lo depuran a las 2 a. m. y lo heredan tres trabajos después. Una consulta que puedes & #39;t skim es una consulta que puedes & #39;t verificar.
una Formateador SQL convierte cualquier consulta, pegada de un registro, un resultado de depuración de ORM's, un compañero de trabajo's Mensaje Slack, un procedimiento almacenado heredado, en SQL constantemente sangrado, consistentemente en mayúsculas y minúsculas revisables con un solo clic. El de Toolz.dev se ejecuta completamente en su navegador, lo que importa más para SQL que para casi cualquier otro texto que usted 'd pegue en una herramienta en línea, porque las consultas de producción llevan su esquema y, a veces, sus datos.
Esta guía cubre cómo usarlo, las convenciones de formato que realmente importan (casive de palabra clave, sangría y guerra de comas eterna) y los flujos de trabajo donde un formateador se paga por sí mismo todos los días.
TL;Dr: Pegue cualquier consulta en el Formateador SQL Toolz.dev y vuelva a SQL con sangría constante y en mayúsculas, instantáneo, gratuito, del lado del cliente, sin registro. El formato nunca cambia lo que hace una consulta ni qué tan rápido se ejecuta; cambia si un humano puede verificarla. Convenciones que vale la pena adoptar: palabras clave en mayúsculas, una cláusula por línea, sangría debajo de cada cláusula, elija un estilo de coma y deje de discutir al respecto. Emparejarlo con el Formateador JSON para la capa de API sobre su base de datos y el Herramienta de diferencia de texto para comparar dos versiones de una consulta.
Características clave
Sangría consistente con un solo clic
El movimiento central del formateador 's: cada cláusula principal - SELECT, FROM, WHERE, GROUP BY, ORDER BY - comienza su propia línea, con columnas, condiciones y uniones sangradas debajo. Este es el "river" Los lectores SQL experimentados en estructuras escanean: el ojo recorre el borde izquierdo leyendo las palabras clave de la cláusula y luego se sumerge en cualquier cláusula que importe. Una consulta formateada de 60 líneas con revisiones claras de la estructura más rápido que uno de 6 líneas sin formato, porque la estructura está haciendo la mitad de la lectura por ti. Mi historia de terror de 340 líneas habría sido una reseña de veinte minutos con esta forma: el tipo de unión cambiado se habría sentado solo en su propia línea, visiblemente equivocado.
Normalización de casos de palabras clave
SELECT frente contra select genuinamente no es ' No importa en ninguna base de datos: las palabras clave SQL no distinguen entre mayúsculas y minúsculas según el estándar, y cada dialecto lo respeta. Sin embargo, es enormemente importante para una base de código, porque la carcasa mixta es un ruido visual que hace que las consultas estructuralmente idénticas parezcan diferentes. Las palabras clave en mayúsculas son la convención más antigua, que data de editores sin resaltado de sintaxis, donde SELECT en mayúsculas era el resaltado. Todavía escribo mayúsculas: las palabras clave aparecen frente a los identificadores minúsculas y sobrevive a todos los contextos que eliminan el resaltado: registros, diferencias, correo electrónico de texto sin formato, salida de terminal. El formateador se normaliza según la convención elegida, por lo que un código base escrito por cinco personas se lee como si hubiera sido escrito por una.
Maneja ORM y salida de registro
Las consultas que más necesitan formatear son las que no han escrito Human: Elocuente y ActiveRecord Output, uniones generadas por Doctrine, los monstruos de una sola línea en su registro de consulta lenta. La salida ORM llega como una línea con alias generados por máquina (t0, t1, laravel_reserved_0), y leerlo sin procesar es cómo te duele la cabeza. Mi uso más frecuente del formateador: tome la consulta del registro de consultas de Laravel #39; o Telescopio, formatéelo y vea realmente lo que ORM decidió hacer, que es el primer paso de cada " ¿Por qué este punto final es lento " investigación, justo antes EXPLAIN.
Tolerancia multidialegena
SQL del mundo real es una familia de dialectos: identificadores de backtick citados por mysql, comillas dobles de postgreSQL y :: Casts, corchetes de SQL Server y TOP, sqlite's acomodado todo. Un formateador útil los maneja todos sin exigir que primero declare un dialecto, preservando la sintaxis específica de dialecto en lugar de "corrección". El estándar ANSI/ISO SQL (ISO/IEC 9075) define el núcleo común, pero nadie escribe SQL estándar puro en la práctica, y un formateador que solo habla el estándar se ahogaría con el primer backtick.
Conserva la semántica, garantizada
Vale la pena indicarlo explícitamente porque es 's el miedo que detiene a las personas: el formato no puede cambiar los resultados. Los espacios en blanco y el caso de las palabras clave no son semánticos en SQL; la única advertencia histórica es esa literales de cadena se comparan con distinción entre mayúsculas y minúsculas o no dependiendo de su intercalación, y un formateador nunca toca el interior de sus cadenas entre comillas. La salida es la misma sentencia, byte-for-byte donde se ejecutan los bytes. EXPLAIN En ambas versiones si quieres verlo: planes idénticos.
lado del cliente, lo que realmente importa aquí
SQL es la categoría de texto más confidencial que habitualmente se pega en las herramientas en línea. Las consultas revelan su esquema (nombres de tablas, nombres de columnas, relaciones) y las consultas copiadas de registros frecuentemente contienen valores literales: correos electrónicos WHERE cláusulas, rangos de identificación, ocasionalmente algo que nunca debería haber estado en una cadena de consulta. los Formateador de Toolz.dev procesa todo en su navegador; nada se transmite. Para SQL específicamente, I' Llame al procesamiento del lado del cliente un requisito, no una característica; verifíquelo en la pestaña Red y luego relájese.
Cómo usar el formateador SQL
Paso 1: Captura la consulta
Copie el SQL desde su fuente: su archivo de migración, un procedimiento almacenado, la salida de depuración de ORM (DB::listen() o telescopio en Laravel, ActiveRecord::Base.logger En Rails), el registro de consulta lenta o la pestaña Consulta de su herramienta APM. Si proviene de un registro, puede haber escapado de comillas o de marcador de posición de parámetros (?, $1) - eso' Está bien, los formateadores manejan marcadores de posición, y verlos claramente suele ser el punto.
Paso 2: Pegar y dar formato
Abre el Formateador SQL, pegar y aparece la versión formateada. No se requiere ceremonia dialectal ni configuración para obtener un buen valor predeterminado. Si su consulta incluye varias declaraciones separadas por punto y coma, se formatean como declaraciones separadas, lo que resulta útil para leer scripts de migración completos.
Paso 3: Léalo como un crítico
Ahora haga lo que existe el formato de cosa para: Escanear el borde izquierdo. ¿Qué tablas se unen y con qué tipos de unión? ¿El WHERE la cláusula tiene las condiciones que espera y son las AND/OR Las agrupaciones entre paréntesis de la forma en que convenirse ellos agrupan? (Prencia de operador en SQL PUTS AND antes de que OR, y las mezclas no entre paréntesis de los dos son la segunda fuente de error más grande que veo en revisión, justo después de los tipos de unión incorrectas). SQL formateado hace que ambos errores sean visibles en segundos.
Paso 4: Cópielo nuevamente, de forma selectiva
Para consultas que se dirigen a su base de código, copie la versión formateada en la migración, el ->select() expresión cruda, la .sql archivo Para la depuración única, no te molestes en hacer ida y vuelta; la copia formateada cumplió su propósito en el momento en que lo leíste. UN LUGAR no Para pegar SQL con formato: volver a los sistemas que almacenan consultas como cadenas de configuración donde las herramientas de diferencial de alguien ahora mostrarán una pared de cambios en el espacio en blanco. Formato para leer siempre; Formatear consultas almacenadas solo cuando estés preparado para ser dueño de la diferencia.
Paso 5: Estandarizar la Convención del Equipo
El mayor valor de Formatter' es la capitalización: elija las convenciones que puede automatizar (el caso de la palabra clave y el ancho de la sangría son los dos que este formateador controla directamente), formatee todo lo nuevo en el camino hacia el código base y la fricción de revisión SQL caiga permanentemente. Escriba la elección en su guía contribuyente. La convención específica elegida importa mucho menos que todos los que usan la misma: una oración que se aplica a todos los debates sobre formato en software y que aproximadamente nadie cree a mitad del debate.
Profundización técnica: las convenciones que vale la pena tener opiniones sobre
carcasa de palabras clave. Palabras clave en mayúsculas, identificadores en minúsculas es la convención dominante y mi recomendación. El argumento es 't tradición - it's robustez. El resaltado de sintaxis desaparece en registros, terminales, comentarios de revisión de código y respuestas de Stack Overflow pegadas en Slack; Las palabras clave en mayúsculas resaltan que viaja con el texto. El contraargumento (minúscula todo, deje que el editor lo resalte) es coherente y I' He trabajado en bases de código que lo usaron felizmente. What' No es coherente es la mezcla, que es lo que se obtiene sin un formateador que imponga la elección.
Una cláusula por línea, contenidos sangrados. La regla estructural con mayor recompensa. SELECT Inicia una línea; sus columnas están con una sangría abajo (o en la misma línea si es corta). todo JOIN obtiene su propia línea con su ON condición visible: las condiciones de unión ocultas en la línea media son donde se esconden los errores de unión incorrecta. WHERE Las condiciones se apilan por línea, alineadas, con AND/OR Liderando cada línea de modo que la estructura lógica lea verticalmente. Cuando las condiciones de una consulta se leen como una columna, una condición que falta se ve como una brecha en un patrón, cuyos ojos humanos son excepcionalmente buenos para detectar.
La guerra de comas. Las comas de cola (después de cada columna) leen naturalmente; las comas principales (antes de cada columna, al inicio de la línea) hacen que la puntuación sea estructural:
-- Trailing (most common)
SELECT
u.id,
u.email,
o.total
-- Leading (the DBA classic)
SELECT
u.id
, u.email
, o.total
Los defensores de las comas principales tienen dos puntos genuinamente buenos: comentar cualquier línea excepto la primera nunca rompe la afirmación, y una coma faltante es visible instantáneamente en el margen izquierdo. Los defensores de las comas finales tienen uno: se parece a cualquier otro lenguaje que escribas. Escribo comas finales y he dejado de sentirme mal por ello, pero tenga en cuenta que SQL, a diferencia de JavaScript o Python modernos, sí lo hace no perdone una coma colgante después de la columna final, razón por la cual existe este debate y por qué el estilo principal se niega a morir en los círculos de DBA. Divulgación completa: el formateador Toolz.dev toma el lado principal y emite comas finales; no tiene modo de coma principal, así que si usted & #39; es una tienda de comas líder comprometida, esta es la única convención que ganó & # 39; reformateo para usted. Elija un estilo de casa, aplíquelo consistentemente y siga adelante.
Qué formatear no funciona. No optimiza. un formateado SELECT * A través de una unión de cinco mesas hay un problema de rendimiento bellamente sancionado. El formateo es el condición previa para la optimización, no se puede razonar sobre una consulta que no se puede leer, pero el razonamiento aún requiere EXPLAIN, Indexar Conciencia y Conocer la forma de sus datos. Pienso en la canalización como: formato, lectura, EXPLAIN, luego optimizar. Saltar el paso uno no te hace más rápido; hace que los pasos de dos a cuatro sean más lentos. La misma disciplina aplica una capa en la API, por lo que el Guía de formateador JSON Hace un argumento estructuralmente idéntico sobre las cargas útiles.
Los comentarios sobreviven. A diferencia de la minificación, el formato conserva los comentarios -- Comentarios de línea y /* */ Los bloques llegan intactos. Úsalos. un -- deliberately LEFT JOIN: include customers with no orders Comentar arriba Una unión es el seguro de error más barato jamás escrito, y es el comentario que necesitaba mi historia de terror de 340 líneas.
Casos de uso comunes
Revisión de código
Sql sin formato en una solicitud de extracción es una revisión que es ' no va a suceder - el revisor ' Los ojos se deslizan fuera de la pared de texto y la aprobación aterriza de todos modos. Formatear la consulta antes de abrir el PR es una cortesía básica con una recompensa mensurable: los tipos de unión, las agrupaciones de condiciones y las listas de columnas se vuelven visibles individualmente, lo que significa que se pueden revisar individualmente. Cada error SQL genuino I' He captado en revisión: la unión incorrecta, sin paréntesis OR, el DELETE falta la mitad de su WHERE cláusula: la capté porque la consulta tenía el formato suficiente para leer línea por línea.
Depuración de consultas generadas por ORM
Los ORM son maravillosos hasta que el punto final es lento, momento en el cual es necesario ver el SQL real, y la salida de ORM es siempre una línea densa. Formatearlo y aparece la historia: el N+1 que se perdió la carga ansiosa, la definición de unión de la relación se agregó silenciosamente, el ORDER BY en una columna sin indexar. En el trabajo de Laravel este es un ritual varias veces semanal: telescopio, copia, formato, muele, arregla el código elocuente, repite. El formateador no diagnostica nada por sí mismo; hace que la consulta sea lo suficientemente legible como para usted lata
Arqueología sobre consultas heredadas
Cada sistema de larga duración los tiene: el procedimiento almacenado de 2015, la vista de informes que nadie se atreve a tocar, la consulta incrustada en un archivo de configuración con el formato original del autor 's (es decir, ninguno). Antes de modificar el SQL heredado, formatéelo y léalo de un extremo a otro - usted & # 39; rutinariamente encontraré condiciones que pueden & # 39; alguna vez sea cierto, se une a tablas que ya no reciben escrituras y la lógica del equipo actual & # 39; sus suposiciones contradicen. Formatear los primeros giros " consulta y quot heredados aterradores; en " consulta larga pero legible, " que es un problema diferente y mejor.
Comparación de versiones de consulta
Cuando los números de un informe 's cambian entre versiones, la pregunta es " lo que cambió en la consulta, " y la respuesta requiere diferenciar dos versiones, lo que solo funciona si ambas tienen el mismo formato primero. Formatee ambos con la misma configuración y luego ejecútelos a través de Herramienta de diferencia de texto: El ruido desaparece y las dos líneas cambiadas están solas. Esta secuencia exacta encontró mi error de unión interna, eventualmente. ahora lo hago antes de que El día y medio de la confusión en lugar de después.
Enseñanza y documentación
SQL en tutoriales, libros de ejecución y documentos internos se lee muchas más veces de las que se escriben, por lectores menos familiarizados con el esquema que el autor. Los ejemplos formateados con palabras clave en mayúsculas y estructura de un concepto por línea son dramáticamente más fáciles de aprender: la estructura enseña junto con el contenido. Cuando escribo documentación con consultas integradas, cada uno revisa primero el formateador; SQL sin formato en documentos le dice al lector que el autor lo hizo ' No espero que nadie lo lea realmente.
Convenciones de formato comparadas
| Elección de la conven | Opción A | Opción B | mi toma |
|---|---|---|---|
| Caso de palabras clave | SELECT (mayúsculas) |
select (mayúsculas) |
Mayúsculas: sobrevive a contextos sin resaltar |
| Caso identificador | Serpiente_caso | Definiciones de la tabla de coincidencia | Definiciones de coincidencia; nunca luches contra el esquema |
| comillas | rastrero (id,) |
liderar (, id) |
Atrás, pero liderar es defendible, solo elige uno |
| Disposición de cláus | Una cláusula por línea | Línea única compacta | uno por línea para cualquier cosa pasada trivial |
AND/OR colocación |
Liderando cada línea de condición | Trailando la línea anterior | Líder: la lógica se lee verticalmente |
| Condiciones de unión | ON en su propia línea o en línea con JOIN |
línea media enterrada | visible con la unión, siempre |
| Ancho de la sangría | 2 espacios | 4 espacios | De cualquiera de los dos, SQL nidifica menos que JSON, por lo que 4 está bien aquí |
Ninguna de estas filas tiene una respuesta incorrecta, y eso ' es precisamente la trampa: debido a que cada opción es defendible, los equipos las vuelven a litigar para siempre a menos que un formateador haga que la decisión sea mecánica. El movimiento ganador es aburrido: elige, configura, formatea todo y dedica el tiempo de argumento recuperado a las cosas que afectan el plan de ejecución. Para el resto del conjunto de herramientas diario relacionado con este, consulte el Guía de herramientas de codificación y el más amplio Kit de herramientas para desarrolladores web.
preguntasrán el
¿Qué hace un formateador SQL?
Un formateador SQL reescribe una consulta 's espacios en blanco, saltos de línea y carcasa de palabras clave en una estructura consistente y legible: cada cláusula en su propia línea, condiciones y columnas sangradas, palabras clave normalizadas en un caso. El significado de la declaración 's no se toca: los analizadores SQL ignoran el formato por completo, por lo que la consulta formateada devuelve resultados idénticos con un plan de ejecución idéntico. El cambio es exclusivamente para los humanos que revisan, depuran y mantienen la consulta.
¿El formato de SQL cambia el rendimiento de las consultas?
No. Los espacios en blanco y el caso de las palabras clave no son semánticos en SQL: la base de datos analiza ambas versiones en la misma representación interna y produce el mismo plan de ejecución, que puede verificar ejecutando EXPLAIN en cada uno. El formato es la condición previa para el trabajo de rendimiento en lugar del trabajo de rendimiento en sí: no puede razonar sobre los índices y unirse al orden en una consulta que no puede leer.
¿Las palabras clave SQL deben ser mayúsculas o minúsculas?
Ambos son válidos (las palabras clave SQL no distinguen entre mayúsculas y minúsculas según el estándar), por lo que se trata de una convención de legibilidad, no de una regla de corrección. Palabras clave en mayúsculas (SELECT, FROM, WHERE) Sigue siendo la opción más común porque actúan como resaltado incorporado en contextos que eliminan colores: registros, diferencias, terminales y mensajes de texto sin formato. Cualquiera que sea el que elija, la coherencia en la base de código importa mucho más que la elección en sí.
¿Qué son las comas líderes en SQL y por qué las personas las usan?
El estilo de coma líder coloca la coma al comienzo de cada línea de columna (, email) en lugar del final del anterior. A los defensores les gusta porque comentar cualquier columna excepto la primera nunca produce un error de sintaxis, y las comas faltantes son visibles instantáneamente en el margen izquierdo: ventajas reales, ya que SQL no ' No tolero una coma colgante después de la columna final como lo hace el JavaScript moderno. Las comas finales siguen siendo más comunes; cualquiera de los dos funciona si se aplica de manera consistente.
¿Puedo formatear SQL generado por un ORM como Eloquent o ActiveRecord?
Sí, y es uno de los mejores usos de un formateador: la salida de depuración ORM llega como una única línea densa con alias generados por máquinas, y formatearla es el primer paso para diagnosticar puntos finales lentos y problemas N+1. Capture la consulta desde su registro ORM's (Telescopio Laravel, registros ActiveRecord), péguela en el Formateador SQLy lea lo que realmente construyó el ORM antes de alcanzar EXPLAIN.
¿Funciona el formateador con la sintaxis de MySQL, PostgreSQL y SQL Server?
Sí, los formateadores prácticos manejan los dialectos principales ' peculiaridades, preservando las comillas invertidas de MySQL, identificadores de comillas dobles de PostgreSQL y :: Casts y corchetes cuadrados de SQL Server en lugar de reescribirlos. El estándar ANSI SQL define el núcleo compartido, pero ninguna base de datos de producción habla SQL estándar puro, por lo que la tolerancia al dialecto es un requisito para que un formateador sea útil en consultas reales.
¿Es seguro pegar consultas de producción en un formateador SQL en línea?
solo en uno del lado del cliente, porque SQL es inusualmente sensible: las consultas exponen su esquema y las consultas copiadas de los registros a menudo contienen valores literales como correos electrónicos o ID en WHERE cláusulas. los Formateador SQL Toolz.dev procesa todo en su navegador sin transmitir ni almacenar nada; verifíquelo usted mismo mirando la pestaña Red mientras pega. Evite los formateadores basados en servidor para cualquier cosa que no sea de producción.
¿El formato conserva los comentarios de SQL?
Sí, ambos -- Comentarios de línea y /* */ Los comentarios de bloque pasan intactos, a diferencia de la minificación, que los elimina. Esto hace que el formato sea seguro para las consultas anotadas y los procedimientos almacenados donde los comentarios tienen intención. Use eso: un comentario de una sola línea que explica un deliberado LEFT JOIN O una condición inusual es la protección más barata contra el próximo desarrollador "fijando" algo que no estaba roto.
