Pega una consulta SQL minificada y obten una salida legible e indentada. Elige el dialecto, el ancho de sangria y las mayusculas de palabras clave; todo se ejecuta localmente.
Devuelve la legibilidad a un muro de SQL. Pega una consulta, de una linea o de mil, y se reformatea mientras escribes. Elige el dialecto para que la sintaxis especifica no se estropee y despues la sangria y las mayusculas que usa tu equipo.
La libreria de formateo SQL no se cargo. Recarga la pagina.
SQL es un estandar mas o menos en el mismo sentido en que lo es la ortografia del ingles. Cada motor implementa el nucleo comun y luego anade sintaxis que nadie mas tiene, y un formateador que no sabe a que motor apuntas o bien analizara mal esa sintaxis o la dejara pasar sin formatear.
Las diferencias no son exoticas. Solo el entrecomillado de identificadores ya divide el terreno: MySQL usa acentos graves, PostgreSQL y el SQL estandar usan comillas dobles, y SQL Server usa corchetes. Un formateador que asume la convencion equivocada puede tratar un identificador entrecomillado como un literal de cadena y reorganizar la consulta alrededor de un limite que no existe. Mas alla del entrecomillado estan LIMIT frente a TOP frente a FETCH FIRST, el operador de conversion :: de PostgreSQL, las variables de T-SQL con prefijo @, las rutas de proyecto de BigQuery entre acentos graves y la clausula QUALIFY de Snowflake. Elegir el dialecto correcto es lo que mantiene todo eso intacto.
El ancho de sangria y las mayusculas parecen cosmeticos, pero determinan el aspecto de tu historial de control de versiones. Formatear solo sirve si es coherente, porque en cuanto dos personas formatean el mismo fichero de forma distinta, cada commit arrastra una oleada de cambios de espaciado irrelevantes y la revision de codigo deja de funcionar. Elige una configuracion, escribela en el repositorio y aplicala mecanicamente.
Las palabras clave en mayusculas son la convencion mas extendida y ayudan a leer una consulta densa, porque las palabras estructurales se separan visualmente de tus tablas y columnas. Las minusculas han ganado terreno en bases de codigo que tratan el SQL como codigo normal y prefieren no gritar. Conservar es la opcion correcta cuando formateas la consulta de otra persona y quieres cambiar la disposicion sin tocar ni un caracter de su texto, lo que deja un diff puramente estructural.
Tabuladores frente a espacios arrastra la discusion de siempre, con un matiz propio de SQL: las consultas acaban pegadas en terminales, sistemas de tickets y clientes de chat que representan un tabulador como ocho columnas. Una consulta muy anidada con tabuladores puede partirse de forma ilegible justo donde es mas probable que la compartas.
Formatear es puramente presentacional. No hara que una consulta vaya mas rapido y no cambia nada del plan que produce el optimizador. Una subconsulta correlacionada bellamente indentada sigue ejecutandose una vez por fila. Usa EXPLAIN para el rendimiento y un formateador para la legibilidad.
Tampoco valida. Esta herramienta analiza lo suficiente para redistribuir el texto, pero no es el analizador del motor y formateara tan contenta una consulta con una columna mal escrita o sin condicion de join. Un formato limpio no es una comprobacion de sintaxis, y la unica autoridad sobre si una consulta es valida es la base de datos donde piensas ejecutarla.
El habito que conviene adoptar junto al formateo es la parametrizacion. Formatear una consulta con los valores concatenados en la cadena hace el riesgo de inyeccion mas legible, pero no menos real. Si te encuentras formateando SQL que incrusta entrada de usuario directamente en el texto, el formato no es el primer problema que hay que arreglar.