Guía de estilo SQL: buenas prácticas de formato

Una guía de estilo SQL es un conjunto de convenciones que hacen las consultas legibles y mantienen consistentes los diffs de un equipo. A SQL en sí no le importa: las palabras clave no distinguen mayúsculas de minúsculas y los espacios en blanco se ignoran, así que SELECT, select y SeLeCt se ejecutan igual, y una sola línea de 200 caracteres devuelve las mismas filas que esa consulta repartida en veinte líneas indentadas. El estilo es para las personas que leerán la consulta después, no para la base de datos.

Si solo necesitas una consulta limpia ahora mismo, pégala en el Formateador SQL, elige tu dialecto y copia el resultado. Pero entender las reglas detrás de ese resultado es lo que te permite fijar un estándar de equipo en lugar de discutirlo en cada pull request. Esta guía recorre las decisiones que importan: mayúsculas de palabras clave, indentación y saltos de línea, nombres, peculiaridades de cada dialecto y cómo automatizar todo el proceso.

Vale la pena un encuadre antes de los detalles. Como SQL ignora los espacios en blanco y las mayúsculas, ninguna de estas reglas la impone la base de datos: existen para las personas que leen, revisan y mantienen la consulta. Eso tiene dos consecuencias. Primero, rara vez hay una sola respuesta “correcta”; la mayoría de estas decisiones consisten en elegir una convención razonable y aplicarla en todas partes, y esta guía intenta ser honesta sobre dónde están las concesiones reales en vez de fingir que un estilo gana siempre. Segundo, como las reglas son convenciones y no requisitos, solo aportan valor cuando se aplican de forma consistente, y por eso cada sección apunta a la misma conclusión: decide una vez y deja que una herramienta lo imponga.

Por qué importa el formato de SQL

El argumento más claro a favor del formato aparece en la revisión de código. Un ORM o un paso de compilación a menudo emite las consultas como una única línea ininterrumpida:

select u.id,u.name,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.active=true group by u.id,u.name order by orders desc

Nadie puede revisar eso. Reformateada, la estructura es evidente y el diff se puede revisar línea por línea:

SELECT
  u.id,
  u.name,
  COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

La depuración se beneficia igual. Cuando copias una consulta de una sola línea de un registro de consultas lentas y tiene tres joins y un WHERE enredado, formatearla primero convierte el “dónde está el error” en un vistazo de medio minuto. El predicado defectuoso queda en su propia línea, los joins se apilan, y un producto cartesiano accidental o un filtro olvidado se vuelven visibles en vez de quedar enterrados en un muro de texto. El mismo truco ayuda cuando lees SQL que generó otro sistema: los constructores de consultas y las herramientas de reportes tienen fama de emitir salidas correctas pero ilegibles.

La consistencia es la ganancia más silenciosa, y con el tiempo la más valiosa. Cuando todos formatean de la misma forma, los diffs muestran solo lo que cambió de verdad (una columna nueva, un filtro ajustado) y no el ruido de la preferencia de espaciado de una persona peleando con la de otra. La atención de quien revisa es finita; gastarla en espacios en blanco recolocados es un desperdicio. El formato consistente también facilita la incorporación: alguien recién contratado lee consultas que se ven todas iguales, aprende la forma del equipo una vez y la aplica en todas partes. Nada de esto exige que nadie formatee a mano, que es el tema de la sección final: tú decides las reglas, una herramienta las aplica.

Una invariante sostiene todo esto, y vale la pena enunciarla con claridad porque se repite a lo largo de esta guía: el formato solo cambia los espacios en blanco, los saltos de línea, las mayúsculas de las palabras clave y los comentarios. Nunca cambia la lógica de la consulta ni sus resultados. Una consulta formateada es la misma consulta. Por eso puedes ejecutar con seguridad la versión desordenada de arriba en el Formateador SQL sin preocuparte por lo que devuelve.

Mayúsculas de palabras clave: UPPERCASE vs lowercase

El debate más antiguo de cualquier guía de estilo SQL es si las palabras clave reservadas deben ir en UPPERCASE o en lowercase. Ambas son válidas, porque SQL no distingue mayúsculas de minúsculas en las palabras clave. El desacuerdo es sobre la legibilidad, y vale la pena entender ambos lados antes de elegir.

El argumento a favor de las palabras clave en UPPERCASE

El argumento tradicional es el contraste visual. Escribir SELECT, FROM, WHERE, JOIN y GROUP BY en mayúsculas hace que las palabras clave resalten frente a los nombres de tablas y columnas en minúsculas, así que puedes recorrer de un vistazo la forma de una consulta, sus cláusulas y su estructura, sin depender de que un editor las coloree.

Eso importa más de lo que parece, porque SQL pasa por muchos sitios que no tienen resaltado de sintaxis: archivos de log, hilos de correo, descripciones de pull requests, un diff en texto plano, un mensaje de Slack, un panel de monitoreo, una traza de pila. En todos ellos, las palabras clave en mayúsculas son lo único que mantiene legible la estructura: quita el resaltado y select id from users where active es una sopa de palabras en minúsculas, mientras que SELECT id FROM users WHERE active se sigue leyendo como una consulta de un vistazo. Esta es la convención que encontrarás en la mayoría de las guías de estilo antiguas, en la documentación de bases de datos y en casi todos los libros de texto de SQL, que es también la razón por la que a muchos desarrolladores les resultan más familiares las palabras clave en mayúsculas aunque su editor las colorearía de todos modos.

El argumento a favor de las palabras clave en lowercase

El contraargumento moderno es que el resaltado de sintaxis resolvió el problema del contraste. Todo editor e IDE colorea las palabras clave de forma distinta, así que ponerlas en mayúsculas es redundante, y para algunos lectores todo en mayúsculas se lee como un grito. También es ligeramente más rápido de escribir sin tener que pulsar shift en cada palabra clave.

El estilo en minúsculas tiene un impulso real en el mundo de la ingeniería de analítica. La comunidad de dbt y varias guías de estilo de equipo muy citadas usan por defecto palabras clave en minúsculas, con la lógica de que el resaltado ya carga el peso visual y las minúsculas mantienen la consulta más calmada de leer. Hay otro punto más sutil a su favor: las palabras clave en minúsculas se sitúan al mismo nivel visual que tus nombres de tablas y columnas en snake_case, así que toda la consulta se lee como un texto consistente y no como dos registros (palabras clave que gritan e identificadores callados) compitiendo por la atención. Si eso es una virtud o un defecto es justo el tipo de cosa sobre la que los equipos discrepan, lo que nos lleva al único veredicto que de verdad se sostiene.

El veredicto: la consistencia gana a la elección

Esta es la parte que de verdad importa: cuál elijas importa mucho menos que elegir una y hacerla cumplir. Una base de código donde la mitad de las consultas gritan SELECT y la otra mitad susurran select es el peor resultado, porque la inconsistencia misma se convierte en ruido. Mezclar mayúsculas y minúsculas en una sola consulta es aún peor.

La razón por la que gana la consistencia es mecánica, no estética. Las mayúsculas inconsistentes hacen que los diffs mientan: quien revisa ve un “cambio” de línea que en realidad es solo alguien reformateando una palabra clave, y el cambio real se esconde entre el ruido. El grep y la búsqueda también se vuelven menos fiables cuando la misma palabra clave aparece en tres formas de capitalización. Un único estilo impuesto elimina toda esa carga al precio de una sola decisión. Así que decide en equipo, escríbelo y deja que una herramienta lo imponga en vez de depender de la disciplina. El Formateador SQL tiene un control de Keywords con tres opciones (UPPERCASE, lowercase y Preserve) para que puedas normalizar a un solo estilo una pila entera de consultas históricas con un clic. La misma consulta, presentada de ambas formas:

-- UPPERCASE
SELECT id, email FROM users WHERE active = true ORDER BY created_at DESC;

-- lowercase
select id, email from users where active = true order by created_at desc;

Elige la que tu equipo prefiera. Lo importante es que todas tus consultas coincidan con ella.

Indentación y saltos de línea

Las mayúsculas deciden cómo se ven las palabras clave. La indentación y los saltos de línea deciden cómo se mapea la lógica de la consulta sobre la página, y aquí es donde reside la mayor parte de la legibilidad.

El estilo “río” vs el estilo de bloque

La sqlstyle.guide de Simon Holywell popularizó el estilo “río”, donde las palabras clave se alinean a la derecha para que un canal vertical de espacio en blanco recorra el centro de la consulta:

SELECT id,
       email,
       created_at
  FROM users
 WHERE active = true
 ORDER BY created_at DESC;

El atractivo es que SELECT, FROM y WHERE quedan alineados por su borde derecho y la lista de columnas se sitúa limpiamente a la derecha del río. Los inconvenientes son prácticos, sin embargo. La alineación depende de la longitud de tu palabra clave más larga, así que agregar un LEFT JOIN puede obligarte a reindentar todo; es doloroso de mantener a mano; y produce diffs ruidosos, porque cambiar la longitud de una palabra clave desplaza el espacio en blanco de las líneas vecinas.

El estilo de bloque (o alineado a la izquierda) empieza cada cláusula principal en el margen izquierdo, en su propia línea, e indenta el contenido de la cláusula:

SELECT
  id,
  email,
  created_at
FROM users
WHERE active = true
ORDER BY created_at DESC;

Este es el valor predeterminado dominante y el que producen la mayoría de las herramientas, porque es estable: agregar una cláusula nunca reacomoda las líneas de arriba, así que los diffs se mantienen pequeños y el diseño sobrevive al formato automático. El estilo río optimiza para cómo se ve una consulta terminada de forma aislada; el estilo de bloque optimiza para cómo cambian las consultas con el tiempo y cómo se revisan en el control de versiones. Para cualquier cosa que viva en un repositorio y se edite, el estilo de bloque es la apuesta más segura, y es lo que asume el resto de esta guía.

Cuántos espacios: 2 vs 4 vs tabulaciones

Una vez que indentas, tienes que decidir cuánto. Las tres respuestas comunes tienen cada una su justificación:

• 2 espacios: el valor por defecto más común. Mantiene los diffs compactos y evita que las consultas anidadas se marchen fuera del borde derecho de la pantalla.
• 4 espacios: da a cada nivel de anidamiento más separación visual, lo que ayuda en consultas con subconsultas profundas o muchos niveles de CTE.
• Tabulaciones: dejan que cada desarrollador elija su propio ancho de visualización sin cambiar el archivo.

Aquí no hay una respuesta universalmente correcta, y por eso el Formateador SQL expone un control de Indent con las tres opciones (2 spaces, 4 spaces, Tab). Elige una y aplícala en todas partes.

Dónde cortar las líneas

El ancho de indentación es la parte fácil. La decisión de mayor impacto es dónde insertar los saltos de línea:

• Columnas de SELECT: una columna por línea para cualquier cosa no trivial, de modo que agregar o quitar una columna toque exactamente una línea en el diff. Las consultas muy cortas pueden quedarse en una sola línea.
• FROM y JOIN: empieza cada join en su propia línea, con la condición ON ya sea al final o indentada debajo. Esto mantiene legible el grafo de joins.
• WHERE: pon cada AND / OR en su propia línea para que la lógica booleana se lea de arriba abajo. Para condiciones mixtas de AND/OR, usa paréntesis e indenta los grupos para que la precedencia sea explícita en lugar de algo que quien lee tenga que deducir.

Son pautas, no leyes. Un SELECT id FROM users WHERE id = 1 no necesita cinco líneas, y forzarlo a ellas perjudica la legibilidad más de lo que ayuda. El criterio es más o menos: corta cuando la consulta tenga más de una o dos columnas, más de una tabla o más de una condición. Por debajo de ese umbral una sola línea es más clara; por encima, corta con decisión. Un buen formateador codifica un umbral sensato por ti, pero vale la pena entender el principio para que la salida nunca te sorprenda.

Aplicadas a la consulta desordenada de una línea de antes, esas reglas producen un diseño donde cada cláusula y cada join son visibles de un vistazo:

SELECT
  u.id,
  u.name,
  COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

Comas iniciales vs comas finales

Una cuestión menor pero persistente: ¿dónde va la coma en una lista de columnas de varias líneas?

-- Leading commas
SELECT
    id
  , email
  , created_at
FROM users;

-- Trailing commas
SELECT
    id,
    email,
    created_at
FROM users;

Las comas iniciales tienen una ventaja real: agregar o quitar una columna cambia una sola línea, y una coma faltante es fácil de detectar porque la línea ofensora destaca. Las comas finales se leen de forma más natural y son mucho más comunes en la práctica. Ambas están bien: elige una y deja que el formateador la aplique para que nadie tenga que volver a pensar en ello.

Convenciones de nombres para tablas y columnas

El formato gobierna los espacios en blanco; los nombres gobiernan los identificadores en sí, y una guía de estilo está incompleta sin ellos.

El estándar de facto para los identificadores SQL es snake_case: todo en minúsculas, palabras separadas por guiones bajos: user_id, created_at, order_items. Tiene ese estatus por una razón concreta, no solo por costumbre: los identificadores en snake_case nunca necesitan comillas y se comportan igual entre dialectos, mientras que camelCase (común en el código de aplicación) choca con la forma en que las bases de datos pliegan las mayúsculas, algo a lo que llegaremos en un momento.

Vale la pena ser explícito sobre por qué esto difiere del código de aplicación. En la mayoría de los lenguajes de programación, el código circundante controla los identificadores, y camelCase o PascalCase son la norma. Los identificadores SQL, en cambio, los interpretan las reglas de plegado de mayúsculas de la propia base de datos, y esas reglas son justo lo que hace frágiles los nombres con mayúsculas y minúsculas mezcladas. snake_case evita todo el problema: no hay mayúsculas que plegar, no hay razón para usar comillas y nada que se comporte distinto de un motor a otro.

Algunas convenciones más que aparecen en casi toda guía de estilo SQL:

• Nombres de tabla en singular vs plural es una división genuina. users (plural, “la tabla contiene usuarios”) y user (singular, “cada fila es un usuario”) tienen ambos defensores. Como con las mayúsculas, la elección importa menos que aplicarla de forma consistente a cada tabla.
• Evita palabras reservadas como identificadores. Nombrar una columna order, user o table te obliga a entrecomillarla en todas partes e invita a errores confusos. Recurre a order_id o account en su lugar.
• Mantén consistente el nombrado de las claves. Una clave primaria llamada id y claves foráneas nombradas <referenced_table>_id (como user_id) hacen los joins predecibles y autodocumentados.

Hay una trampa que vale la pena señalar de forma explícita, porque muerde a los equipos que nombran las columnas de la base de datos igual que nombran las variables de aplicación. En PostgreSQL, un identificador sin comillas se pliega a minúsculas, así que SELECT userId FROM t en realidad busca una columna llamada userid. En el momento en que lo entrecomillas —"userId"— la base de datos preserva las mayúsculas y trata "userId" y userid como dos columnas diferentes:

-- Creates a column whose real name is lowercase "userid"
CREATE TABLE t (userId integer);

-- Both of these work — the name was folded to lowercase
SELECT userId FROM t;
SELECT userid FROM t;

-- This fails: "column \"userId\" does not exist"
-- The quotes force an exact, case-sensitive match
SELECT "userId" FROM t;

Ten en cuenta que las distintas bases de datos pliegan las mayúsculas en direcciones diferentes (Oracle pliega los identificadores sin comillas a mayúsculas, varias otras a minúsculas), así que los identificadores entrecomillados con mayúsculas y minúsculas mezcladas ni siquiera son portables. Lo limpio es evitar por completo los identificadores entrecomillados con mayúsculas y minúsculas mezcladas y atenerte a snake_case, que esquiva el problema y mantiene tu esquema legible en cualquier dialecto.

Para una comparación más a fondo de camelCase, snake_case y kebab-case —incluyendo cuándo cada uno es la opción correcta en código y datos— consulta la guía de convenciones de nombres.

Formato entre dialectos de SQL

Todo lo anterior es en gran medida agnóstico al dialecto: mayúsculas, indentación, saltos de línea y nombres se aplican sin importar a qué base de datos apuntes. Pero “formatea este SQL” choca con un muro en el momento en que tu consulta usa sintaxis específica de una base de datos, porque un parser genérico que no reconoce esa sintaxis la destrozará: puede partir un token en el lugar equivocado, malinterpretar un operador, o tratar un carácter de comillas como delimitador de cadena y tragarse media consulta. Aquí es donde el formato consciente del dialecto demuestra su utilidad, y es la razón por la que el formateador te pide elegir primero una base de datos en vez de adivinarla. Las diferencias de abajo son las que más a menudo encuentras en las consultas del día a día.

Operación	PostgreSQL	MySQL / MariaDB	SQL Server (T-SQL)	Oracle	Standard SQL
Concatenación de cadenas	|| o CONCAT()	CONCAT()	+ o CONCAT()	|| o CONCAT()	||
Valor de respaldo para NULL	COALESCE()	COALESCE() / IFNULL()	COALESCE() / ISNULL()	COALESCE() / NVL()	COALESCE()
Limitar filas	LIMIT	LIMIT	TOP / OFFSET … FETCH	FETCH FIRST	FETCH FIRST
Entrecomillado de identificadores	comillas dobles ("…")	comillas invertidas	corchetes ([…])	comillas dobles ("…")	comillas dobles ("…")

Concatenación de cadenas y manejo de NULL

Dos de las operaciones cotidianas más comunes se escriben de forma diferente entre dialectos.

Concatenación de cadenas:

-- PostgreSQL, Oracle, SQLite (standard operator)
SELECT first_name || ' ' || last_name AS full_name FROM users;

-- SQL Server (T-SQL uses +)
SELECT first_name + ' ' + last_name AS full_name FROM users;

-- Portable across dialects
SELECT CONCAT(first_name, ' ', last_name) AS full_name FROM users;

Valores de respaldo para NULL:

-- Standard SQL (works everywhere)
SELECT COALESCE(nickname, name) AS display_name FROM users;

-- SQL Server only
SELECT ISNULL(nickname, name) AS display_name FROM users;

-- MySQL / MariaDB only
SELECT IFNULL(nickname, name) AS display_name FROM users;

Un formateador configurado con el dialecto equivocado puede no entender ISNULL o el operador || y puede malinterpretar la consulta circundante.

Limitación de filas y entrecomillado de identificadores

Limitar las filas de resultado es una de las piezas de sintaxis que más divergen entre dialectos:

-- PostgreSQL, MySQL, SQLite
SELECT id, name FROM users ORDER BY created_at DESC LIMIT 10;

-- SQL Server (T-SQL)
SELECT TOP 10 id, name FROM users ORDER BY created_at DESC;

-- Standard SQL / Oracle
SELECT id, name FROM users ORDER BY created_at DESC FETCH FIRST 10 ROWS ONLY;

El entrecomillado de identificadores también se divide de tres maneras. Cuando debes entrecomillar un identificador (normalmente para usar una palabra reservada o preservar las mayúsculas) el delimitador depende de la base de datos:

-- MySQL / MariaDB use backticks
SELECT `order`, `user` FROM `select`;

-- SQL Server (T-SQL) uses square brackets
SELECT [order], [user] FROM [select];

-- Standard SQL (PostgreSQL, Oracle, SQLite) uses double quotes
SELECT "order", "user" FROM "select";

Un formateador que cree que las comillas invertidas de MySQL son delimitadores de cadena, o que los corchetes de T-SQL son otra cosa, producirá una salida rota. La configuración del dialecto es lo que le dice cuál es cuál. Es también la razón por la que copiar y pegar una consulta entre bases de datos rara vez es un cambio limpio: la misma intención lógica (concatenar dos cadenas, recurrir a NULL, limitar a diez filas, entrecomillar una palabra reservada) se escribe de cuatro formas distintas entre los dialectos, y solo el parser que conoce tu base de datos puede reformatearla sin corromperla.

Por qué importa el formato consciente del dialecto

Por eso el Formateador SQL viene con nueve dialectos (PostgreSQL, MySQL, SQL Server (T-SQL), BigQuery, Snowflake, Oracle, SQLite, MariaDB y Standard SQL) y no con un único modo genérico. Seleccionar el correcto significa que el parser maneja bien las cadenas con comillas de dólar de PostgreSQL y los casts ::, los identificadores entre corchetes y TOP de T-SQL, las funciones específicas de warehouse de BigQuery y Snowflake, y las reglas de entrecomillado de arriba, en vez de adivinarlas y equivocarse. Elige tu base de datos real del desplegable antes de formatear, y la salida vuelve correcta e idiomática.

Automatización del formato de SQL

Leer las reglas es una cosa; nadie debería aplicarlas a mano. El sentido de una guía de estilo es que una máquina la imponga. Hay tres lugares donde conectar el formato, según cuánta fricción quieras eliminar.

En tu editor (formato al guardar)

La opción de menor esfuerzo es formatear automáticamente cada vez que guardas. VS Code tiene extensiones de formateador SQL que se ejecutan al guardar, y JetBrains DataGrip y las herramientas de base de datos de otros IDE incluyen un formateador integrado que puedes asignar a una pulsación de tecla o a un hook de guardado. Una vez configurado, tus consultas nunca quedan sin formatear, el mismo modelo que Prettier para JavaScript o gofmt para Go. El inconveniente es que la configuración del editor vive en la máquina de cada desarrollador, así que el formato al guardar mantiene ordenado tu SQL pero no garantiza por sí solo que lo esté el del resto del equipo. Para eso necesitas la siguiente capa.

En CI con un linter

Para imponer el estilo en todo un equipo, mueve la verificación a la integración continua. Un linter de SQL como sqlfluff analiza y corrige automáticamente: codificas tus reglas (dialecto, mayúsculas de palabras clave, indentación, colocación de comas) en un archivo de configuración .sqlfluff, ejecutas sqlfluff lint para marcar las violaciones y sqlfluff fix para repararlas, y haces que CI falle cualquier pull request que se desvíe del estilo acordado. Es la misma idea que ESLint o Prettier vigilando un repositorio de frontend: el estilo deja de ser un comentario de revisión que alguien tiene que acordarse de dejar y se convierte en una verificación que pasa o falla y que la máquina nunca olvida. La recompensa es que los debates de estilo ocurren una vez, cuando escribes la configuración, y no en cada pull request.

Formato online puntual

A veces solo tienes una consulta fea y ningún deseo de instalar nada: un fragmento de un log, el mensaje de Slack de un colega, una consulta que estás pegando en la documentación. Para eso, pégala en el Formateador SQL, elige el dialecto, las mayúsculas y la indentación, y copia el resultado limpio.

El detalle de la privacidad importa aquí, y es fácil pasarlo por alto. Muchos formateadores online envían el texto que pegas a un servidor para hacer el trabajo, lo que significa que una copia de tu consulta (nombres de tablas, nombres de columnas, a veces valores literales de un incidente de producción) sale de tu máquina. El Formateador SQL se ejecuta enteramente en tu navegador, así que tu SQL nunca se sube a ningún lado. Eso hace seguro formatear consultas que tocan esquemas de producción o lógica propietaria, que es justo la situación en la que más quieres un formato limpio y menos quieres entregar tu consulta a un tercero. Si estás lidiando con otros formatos en el mismo flujo de trabajo, el hermano Formateador JSON funciona igual: el mismo procesamiento en el navegador, la misma copia con un clic.

Los tres enfoques no son mutuamente excluyentes, y la mejor configuración suele combinarlos: formato al guardar para el ciclo interno rápido mientras escribes, un linter en CI como respaldo que impone el estándar del equipo, y un formateador online para los fragmentos desechables que nunca tocan tu repositorio. Cualquiera al que recurras, recuerda la invariante una última vez: ninguna de estas herramientas cambia lo que hace tu consulta. Reacomodan los espacios en blanco, los saltos de línea, las mayúsculas y los comentarios, nada más.

Preguntas frecuentes

¿Las palabras clave de SQL deben ir en mayúsculas o minúsculas?

Ambas son válidas, porque las palabras clave de SQL no distinguen mayúsculas de minúsculas. UPPERCASE hace que las palabras clave destaquen en entornos sin resaltado de sintaxis, como logs y diffs; lowercase es más fácil de escribir y encaja con los editores modernos que ya colorean las palabras clave. Lo que de verdad importa es que todo el equipo elija una y un formateador la imponga: mezclar mayúsculas y minúsculas es la peor opción.

¿Cuál es la mejor indentación para SQL?

Dos espacios es el valor por defecto más común y mantiene los diffs compactos; cuatro espacios facilita la lectura de consultas muy anidadas; las tabulaciones dejan que cada desarrollador elija su propio ancho de visualización. No hay una sola respuesta correcta: elige una y aplícala de forma consistente en todo tu equipo. La mayoría de los formateadores de SQL, incluido este, admiten las tres opciones.

¿Cómo formateo SQL automáticamente?

Hay tres maneras de formatear SQL automáticamente: formato al guardar en tu editor (VS Code o DataGrip), un linter en CI como sqlfluff que corrige el estilo de forma automática, o un formateador SQL online para el pegado puntual. La vía online es la más rápida porque no necesita instalación: solo pega, elige tu dialecto y copia el resultado.

¿Debo usar comas iniciales o finales en SQL?

Las comas iniciales (coma al inicio de cada línea) dan diffs más limpios al agregar o quitar columnas y hacen fácil detectar una coma faltante; las comas finales (coma al final) se leen de forma más natural y son más comunes. Ambas son aceptables en cualquier guía de estilo SQL: la clave es elegir una y dejar que un formateador la aplique automáticamente.

¿Formatear SQL cambia cómo se ejecuta la consulta?

No. Formatear SQL solo cambia los espacios en blanco, los saltos de línea, las mayúsculas de las palabras clave y los comentarios; nunca cambia la lógica de la consulta. Una consulta formateada devuelve exactamente los mismos resultados que la original, por lo que es completamente seguro embellecer incluso consultas de producción antes de revisarlas o ejecutarlas.

¿Qué convención de nombres debo usar para tablas y columnas de SQL?

snake_case —todo en minúsculas con guiones bajos— es el estándar de facto para los nombres de tablas y columnas de SQL porque evita el entrecomillado y se mantiene seguro entre dialectos. Mantén las claves primarias (id) y las foráneas (user_id) nombradas de forma consistente, y evita usar palabras reservadas como order o user como identificadores para prevenir dolores de cabeza con las comillas.

¿Cómo formateo SQL para un dialecto específico como PostgreSQL o T-SQL?

Selecciona primero el dialecto correspondiente en el formateador. El modo PostgreSQL maneja bien los casts :: y las cadenas con comillas de dólar; el modo SQL Server (T-SQL) entiende los [identifiers] entre corchetes y TOP. Elegir el dialecto equivocado deja que un parser genérico destroce la sintaxis específica del dialecto, así que configúralo siempre a tu base de datos real antes de formatear.

¿Existe una guía de estilo SQL estándar?

No hay un estándar oficial, pero existen varias muy referenciadas: la sqlstyle.guide de Simon Holywell y las guías de estilo públicas de equipos como Mozilla y la comunidad de dbt. Su consenso compartido —indentación consistente, identificadores en snake_case y un salto de línea antes de cada cláusula principal— es lo que esta guía codifica, y un formateador puede imponértelo.