Última actualización: 2026-10-09

Contenido de esta página

• ¿Qué es SQL?
• ¿Para qué sirve SQL?
• Pedir qué, no cómo: ¿por qué se dice que SQL es declarativo?
• ¿Cómo funciona SQL? Del texto que usted escribe al plan de ejecución
• ¿SQL es un lenguaje de programación?
• Las familias de sentencias SQL: DDL, DML, DQL, DCL y TCL
• Historia de SQL: de Codd a la norma ISO/IEC 9075
• ¿Quién usa SQL hoy y por qué sigue vigente?
• Qué guía de SQL leer según lo que busca
• ¿Qué cambia cuando quien pregunta sabe SQL?

Paola (el nombre es ficticio y la escena, compuesta) coordina el programa de becas de una universidad en Bucaramanga. Un jueves, la rectoría le pide un dato para la reunión del lunes. Quiere saber cuántos becarios vienen de municipios de Santander que no son Bucaramanga ni su área metropolitana.

Los datos existen. Están en el sistema académico, a dos clics de su escritorio. Pero Paola no sabe pedirlos, así que abre una solicitud al área de sistemas, que ya tiene treinta en fila. El ingeniero le contesta el martes siguiente, cuando la reunión ya pasó. Escribir la consulta y correrla le tomó cinco minutos.

A Paola no le faltaban datos ni computador. Le faltaba el idioma con el que se le hacen preguntas a una base de datos.

Ese idioma se llama SQL: un lenguaje en el que usted describe el resultado que necesita, por ejemplo «los becarios de Santander que no viven en el área metropolitana», y el sistema se encarga de buscarlo.

¿Qué es SQL?

SQL es el idioma estándar de las bases de datos relacionales, las que guardan la información en tablas conectadas entre sí. Con él se consultan datos, pero también se crean tablas, se cambian registros y se reparten permisos. Lo define una norma internacional que publican la ISO (Organización Internacional de Normalización) y la IEC (su par en electrotecnia), y que se llama ISO/IEC 9075 [1].

La documentación de Oracle, una de las empresas que fabrican gestores de bases de datos, lo pone sin rodeos: todas las sentencias de SQL son instrucciones para la base de datos [2]. Un gestor es el programa que administra la base y custodia los datos. Usted no le dice al computador qué hacer paso a paso; le da una orden a ese programa.

En el caso de SQL Server, el gestor de Microsoft, la regla no tiene excepciones. Toda herramienta o aplicación que se comunica con una de sus bases de datos lo hace enviando comandos en la versión de SQL de esa empresa [3].

Structured Query Language: ¿qué significa la sigla SQL?

SQL son las siglas en inglés de Structured Query Language, que en español sería lenguaje estructurado de consulta [4]. El nombre viene de uno anterior, SEQUEL (Structured English Query Language), con el que IBM, la empresa estadounidense de computadores, bautizó la primera versión [5]. Después se acortó a SQL, y Oracle anota que todavía se pronuncia como el nombre viejo, sequel [5].

En la norma, el nombre formal es todavía más seco: Database Language SQL, lenguaje de bases de datos SQL [1].

Un ejemplo con datos colombianos

Para ver SQL en acción no hace falta un sistema universitario. El DANE (Departamento Administrativo Nacional de Estadística, la entidad de las cifras oficiales) publica en el portal datos.gov.co la Divipola: la lista oficial de códigos de departamentos y municipios del país [6]. La versión vigente tiene corte al 30 de diciembre de 2024 [6]. Casi todas las filas son municipios (unas pocas son áreas no municipalizadas), y la columna dpto trae el nombre del departamento [6].

Suponga que carga ese archivo en una tabla llamada divipola. Esta consulta pregunta cuántos municipios tiene Santander:

-- Corre igual en SQLite 3 y en PostgreSQL 18.
-- Supone una tabla divipola con las columnas del archivo del DANE.
SELECT COUNT(*) AS municipios   -- cuente las filas y llame "municipios" al resultado
FROM divipola                   -- búsquelas en la tabla divipola
WHERE dpto = 'SANTANDER';       -- y quédese solo con las de Santander

La respuesta es una sola fila con el número 87: el conjunto de datos del DANE trae 87 filas de Santander, todas de tipo municipio [6]. Cada palabra hace un trabajo. SELECT (seleccionar) dice qué se quiere, COUNT (contar) pide el número de filas, FROM (desde) indica la tabla y WHERE (donde) pone la condición.

Fíjese en lo que la consulta no dice. No indica en qué orden revisar las filas, ni dónde están guardadas en el disco, ni cómo contarlas. Solo describe el resultado.

¿Para qué sirve SQL?

SQL sirve para hacerle a una base de datos cinco clases de pedidos: consultar información, definir cómo se organiza, agregar o cambiar registros, decidir quién puede hacer qué y agrupar cambios para que se cumplan completos. Un analista lo usa para sacar cifras sin esperar a nadie. Un programador, para que su aplicación guarde y recupere datos.

Oracle resume el alcance del lenguaje en su documentación. Con las mismas sentencias se consultan datos, se insertan, actualizan y borran filas, se crean y modifican objetos, se controla el acceso y se fijan reglas de integridad [2]. Todo eso cabe en un solo idioma.

La segunda ventaja es que ese idioma se comparte. Todos los gestores relacionales importantes entienden SQL, dice la misma documentación, así que lo que usted aprenda en uno le sirve en otro [2]. Para Paola eso significa que no tendría que aprender un idioma distinto si mañana la universidad cambia de sistema.

SQL en una base de datos: ¿qué es una «base de datos SQL»?

«Base de datos SQL» es una forma corriente, aunque imprecisa, de llamar a una base de datos relacional: una que se crea, se consulta y se administra con SQL. La base es el depósito de los datos. SQL es el idioma para hablarle. Por eso SQL Server, MySQL o PostgreSQL no son lenguajes: son gestores que entienden SQL [2].

La confusión viene del nombre de algunos productos, que llevan la sigla. Si quiere entender qué es una base de datos, qué tipos existen y en qué se diferencian las relacionales de las NoSQL, empiece por la guía de bases de datos.

Pedir qué, no cómo: ¿por qué se dice que SQL es declarativo?

SQL es un lenguaje declarativo: usted describe el resultado que quiere y el sistema decide los pasos para obtenerlo. En un lenguaje imperativo, como Python o C, quien programa escribe esos pasos uno por uno. Se parece a tomar un taxi: usted da la dirección de destino y el conductor escoge las calles.

Dentro del gestor, ese conductor es el planificador de consultas, la parte del motor que elige el método para resolver cada pedido. El equipo que desarrolla SQLite, otro motor de bases de datos, lo resume en su documentación sobre el planificador, actualizada en 2026: «Cuando se programa en SQL, se le dice al sistema qué se quiere calcular, no cómo calcularlo» [7].

La misma página da la escala del problema que resuelve el planificador. Para una sola sentencia puede haber cientos, miles o incluso millones de algoritmos distintos, y todos llegan a la respuesta correcta, aunque unos son más rápidos que otros [7].

Microsoft lo explica con la orden de consulta. Una sentencia SELECT no dice los pasos exactos que debe seguir el servidor, así que el servidor debe analizarla para encontrar la forma más eficiente de sacar los datos [8]. A ese trabajo lo llama optimizar la consulta [8].

Sin SQL, alguien tendría que escribir un programa que abra el archivo, lea cada fila, compare el departamento, sume uno cuando coincida y cierre el archivo. La documentación de SQLite calcula que unas pocas líneas de SQL pueden reemplazar cientos o miles de líneas de código que describen pasos [9]. Menos líneas, menos errores.

¿Cómo funciona SQL? Del texto que usted escribe al plan de ejecución

Una consulta SQL llega al gestor como simple texto. Antes de tocar un dato, el gestor revisa que esté bien escrita, la convierte en una estructura interna, arma varias maneras de resolverla, estima cuánto costaría cada una y ejecuta la más barata. La receta que resulta de ese cálculo se llama plan de ejecución.

Para el gestor, la entrada es una secuencia de comandos, y cada comando es una serie de palabras que termina en punto y coma [10]. La documentación de PostgreSQL 18, la versión vigente de ese gestor, describe en cinco etapas lo que pasa con cada consulta [11]:

1. Conexión. El programa abre una conexión con el servidor, le envía la consulta y espera la respuesta [11].
2. Análisis. Un componente revisa que la sintaxis sea correcta y arma un árbol de consulta, que es la representación interna de lo que se pidió [11].
3. Reescritura. El sistema aplica reglas guardadas en su catálogo interno. Por ejemplo, si la consulta usa una vista (una consulta guardada que se usa como si fuera una tabla), la traduce a las tablas reales [11].
4. Planificación. El planificador arma todos los caminos posibles hacia el mismo resultado, estima el costo de cada uno y escoge el más barato [11].
5. Ejecución. El ejecutor recorre el plan, lee las filas, ordena, une tablas, aplica las condiciones y devuelve el resultado [11].

El ejemplo que da la propia documentación es sencillo. Si la tabla tiene un índice (una estructura auxiliar que, como el de un libro, señala dónde está cada valor), hay al menos dos caminos: leerla completa, fila por fila, o ir por el índice [11]. El planificador calcula cuál cuesta menos.

Microsoft describe las mismas piezas con otras palabras. El optimizador recibe tres cosas: la consulta, la estructura de la base de datos y estadísticas sobre los datos [8]. Lo que entrega es el plan de ejecución [8].

SQLite llega al mismo lugar por otro camino. Traduce cada sentencia a código intermedio, unas instrucciones que luego corre un intérprete interno, y a ese resultado lo llama sentencia preparada [9]. Su documentación lo compara con compilar un programa: entra texto que una persona puede leer y sale algo que la máquina puede ejecutar [9].

Cómo ver el plan con EXPLAIN en PostgreSQL 18

Usted puede pedirle al gestor que le muestre el plan antes de ejecutar nada. En PostgreSQL 18 basta con escribir la orden EXPLAIN (explicar) delante de la consulta [12]:

-- PostgreSQL 18. EXPLAIN muestra el plan elegido; no ejecuta la consulta.
EXPLAIN
SELECT nom_mpio
FROM divipola
WHERE dpto = 'SANTANDER';

La salida es un árbol con una línea por nodo, es decir, por cada paso del plan [12]. Si la tabla divipola no tiene índices, el plan tiene un solo nodo, Seq Scan on divipola: un recorrido secuencial que lee la tabla completa. Debajo aparece una línea Filter con la condición del WHERE, porque ese nodo revisa cada fila y deja pasar solo las que cumplen [12].

Cada línea trae además estimaciones de costo y de número de filas [12]. Esas cifras dependen de los datos de cada instalación, así que su pantalla mostrará las suyas. Leer planes más complejos y acelerarlos con índices será el tema de la guía de optimización de consultas SQL, que está en preparación.

¿SQL es un lenguaje de programación?

Sí, pero de un tipo particular. SQL es un lenguaje de programación declarativo y especializado en datos: sirve para describir resultados sobre tablas, no para construir una aplicación completa. En su origen no tenía ciclos ni condiciones del tipo «si pasa esto, haga aquello»; los gestores le añadieron esas piezas con extensiones propias.

Las dos posturas aparecen en la documentación oficial. SQLite sostiene que SQL sí es un lenguaje de programación, distinto de C, JavaScript, Python o Go porque es declarativo y aquellos son imperativos [9]. Oracle prefiere otra etiqueta: técnicamente, dice, SQL es un sublenguaje de datos, y en eso se diferencia de los lenguajes de propósito general como C [2].

La diferencia está en lo que le faltaba. Las sentencias de control de flujo, como los ciclos, las condiciones y el manejo de errores, no formaban parte de SQL ni de su norma al principio [2]. Hoy están en una parte de la norma dedicada a los módulos almacenados, conocida como SQL/PSM [2] [1].

Cada gestor ofrece, además, su propio lenguaje con pasos y ciclos. En Oracle se llama PL/SQL (su extensión procedimental), y la empresa lo describe como parecido a esa parte de la norma [2]. En Microsoft, la versión propia del lenguaje se llama Transact-SQL [3]. PostgreSQL trae uno llamado PL/pgSQL [13].

La documentación de PostgreSQL explica para qué sirven. SQL es portátil y fácil de aprender, pero el servidor ejecuta cada sentencia por separado [13]. Con un lenguaje procedimental, un bloque de cálculos y una serie de consultas se agrupan dentro del propio servidor, lo que ahorra idas y vueltas entre el programa y la base [13].

Mi respuesta práctica para quien empieza: trate SQL como un lenguaje de programación de verdad, con su sintaxis y sus errores, pero no espere construir con él una aplicación entera. Lo normal es combinarlo con otro lenguaje. Cómo conectarse a una base de datos desde Python será tema de la guía de Python para análisis de datos, que está en preparación.

Las familias de sentencias SQL: DDL, DML, DQL, DCL y TCL

Las sentencias de SQL se suelen agrupar en cinco familias según lo que hacen: definir la estructura, modificar los datos, consultarlos, dar permisos y controlar transacciones. Las siglas en inglés de esas familias son las que aparecen en cursos y ofertas de empleo. Sirven para orientarse, pero no son una clasificación única: cada fabricante agrupa las sentencias a su manera.

Familia	Para qué sirve	Sentencias típicas	Ejemplo en un programa de becas
DDL · lenguaje de definición de datos	Crear, cambiar o borrar la estructura: tablas, vistas, índices	CREATE, ALTER, DROP, TRUNCATE TABLE [14]	Crear la tabla de becas
DML · lenguaje de manipulación de datos	Agregar, cambiar o borrar filas	INSERT, UPDATE, DELETE, MERGE [14]	Registrar un becario nuevo
DQL · lenguaje de consulta de datos	Leer datos sin cambiarlos	SELECT, que Oracle y Microsoft cuentan dentro del DML [15] [14]	Contar becarios por municipio
DCL · lenguaje de control de acceso	Dar o quitar permisos	GRANT, REVOKE; Oracle los cuenta dentro del DDL [15]	Dejar que un analista solo lea
TCL · control de transacciones	Agrupar cambios que se confirman completos o se deshacen	COMMIT, ROLLBACK, SAVEPOINT [15]; en PostgreSQL, BEGIN abre la transacción [16]	Cambiar el valor de una beca sin dejar el registro a medias

La muestra que sigue trae una sentencia de cada familia. La sintaxis es válida en PostgreSQL 18; en SQLite corre todo menos la línea de permisos.

-- Una muestra por familia (PostgreSQL 18). En SQLite corre todo menos GRANT.

-- DDL: crear la estructura
CREATE TABLE becas (
  id       INTEGER PRIMARY KEY,
  cod_mpio TEXT,       -- código DANE del municipio; '68001' es Bucaramanga
  valor    INTEGER     -- valor de la beca, en pesos
);

-- DML: agregar una fila
INSERT INTO becas (id, cod_mpio, valor) VALUES (1, '68001', 1500000);

-- DQL: consultar sin cambiar nada
SELECT cod_mpio, valor FROM becas;

-- DCL: dejar que el rol analista solo lea (el rol debe existir antes)
GRANT SELECT ON becas TO analista;

-- TCL: un cambio que se confirma completo
BEGIN;
UPDATE becas SET valor = 1600000 WHERE id = 1;
COMMIT;

Las diferencias entre fabricantes se notan en las orillas. Microsoft separa, entre otras categorías, las sentencias de definición, las de manipulación y las de permisos [14]. Oracle clasifica dar y quitar permisos con GRANT y REVOKE (conceder y revocar) como parte de la definición de datos, el DDL, y llama a SELECT una forma limitada de manipulación de datos [15].

SQLite, por su parte, no tiene GRANT ni REVOKE. Como es un motor incrustado (vive dentro del propio programa, sin servidor aparte) que lee y escribe un archivo común, los únicos permisos posibles son los del sistema operativo sobre ese archivo [17].

Cada familia, con todas sus sentencias, tendrá su desarrollo en la guía de lenguajes de bases de datos, que está en preparación.

Historia de SQL: de Codd a la norma ISO/IEC 9075

SQL nació en IBM en los años setenta para poner en práctica una idea de 1970: el modelo relacional de Edgar F. Codd [18]. Dos investigadores de la empresa, Donald Chamberlin y Raymond Boyce, diseñaron su primera versión, llamada SEQUEL [4] [19]. En 1986 se convirtió en norma de Estados Unidos y en 1987, en norma internacional [20] [21].

Codd era un matemático formado en Oxford que trabajaba en el laboratorio de investigación de IBM en San José, California [4]. En junio de 1970 publicó en la revista Communications of the ACM el artículo que propuso el modelo relacional [18]. Oracle lo describe hoy como el modelo aceptado como definitivo para los gestores relacionales [5].

Al modelo le faltaba un idioma para usarlo. En 1973, un grupo de programadores de IBM emprendió System R, una implementación del modelo a escala industrial [4]. Dentro de ese esfuerzo, Chamberlin y Boyce desarrollaron SQL y, a la vez, sistemas para traducir automáticamente las consultas de alto nivel en planes de ejecución eficientes [4].

Es la misma idea del planificador que vimos arriba. Lleva más de medio siglo funcionando.

El artículo que presentó el lenguaje, SEQUEL: A Structured English Query Language, es de 1974 [19]. Sus autores lo pensaron tanto para programadores profesionales como para usuarios ocasionales de bases de datos. Por eso lo armaron con plantillas de palabras en inglés que imitan la manera como la gente usa una tabla para encontrar información [19].

Año	Hito	Fuente
1970	Codd publica el artículo del modelo relacional	[18]
1973	IBM emprende System R	[4]
1974	Chamberlin y Boyce presentan SEQUEL	[19]
1979	Relational Software, hoy Oracle, lanza la que la propia empresa presenta como la primera implementación comercial de SQL	[5]
1986	El ANSI aprueba la primera norma de SQL, X3.135-1986, el 16 de octubre	[20]
1987	La ISO publica en junio su primera edición, ISO 9075:1987	[21]
1992	Versión SQL-92, con tres niveles de conformidad: de entrada, intermedio y completo	[1]
1999 a 2016	Revisiones SQL:1999, SQL:2003, SQL:2006, SQL:2008, SQL:2011 y SQL:2016	[1]
2023	Versión vigente, SQL:2023; la parte 1 de la norma va en su sexta edición	[1] [22]

El ANSI es el instituto que coordina las normas técnicas de Estados Unidos. Cuando el ANSI y la ISO publican a la vez una norma de SQL, cada organismo le pone el nombre según sus convenciones, pero los textos son técnicamente idénticos, explica Oracle [2].

Cada versión de la norma reemplaza a la anterior. Por eso, advierte la documentación de PostgreSQL, declarar conformidad con una versión vieja no tiene valor oficial [1]. Y la norma sigue en movimiento: el registro de la ISO marca la parte 1 de 2023 como una norma que se va a revisar [22].

La historia de las bases de datos como tecnología tendrá su propia guía. Esta sección se queda con la parte que explica el lenguaje.

¿Quién usa SQL hoy y por qué sigue vigente?

SQL lo usan analistas de datos, programadores y administradores de bases de datos, además de cualquier profesional que necesite sacar sus propias cifras de un sistema. Sigue vigente porque lo entienden los gestores relacionales importantes, porque una norma internacional lo mantiene al día y porque lo aprendido en un gestor sirve en otro.

Hay una pista de cuánto se usa en la encuesta anual de desarrolladores de Stack Overflow, un foro de preguntas de programación. En su edición de 2026, el 58,4 % de quienes contestaron la pregunta sobre lenguajes dijo haber usado SQL [23]. Solo JavaScript lo superó, con 62,0 % [23].

Es una pista y no un censo. La encuesta se difundió por los canales del propio sitio entre el 23 de junio y el 5 de agosto de ese año, y reunió 30.903 respuestas de 169 países [23]. Quien responde es, sobre todo, gente que ya frecuenta ese foro.

La segunda razón es la portabilidad, aunque tiene límites. PostgreSQL cumple al menos 170 de las 177 características obligatorias del núcleo de la norma de 2023 [1]. Su documentación añade que ningún gestor actual afirma cumplir el núcleo completo de esa versión [1]. Por eso el mismo código no siempre corre igual en todos lados: cada gestor habla un dialecto. Esas diferencias tendrán su propia guía, dialectos de SQL, que está en preparación.

En Colombia la barrera de entrada no es el precio. Hay gestores gratuitos, como los que reseña la guía de bases de datos, y datos públicos para practicar, como la Divipola del DANE [6]. La barrera es el idioma.

SQL es la herramienta para sacar los datos. Qué hacer con ellos después es el oficio del análisis de datos, una de las etapas de la ciencia de datos. Y qué empleos piden SQL y cuánto pagan lo tratará la guía de rutas y carreras en datos, que está en preparación.

Qué guía de SQL leer según lo que busca

SQL se aprende mejor en orden: primero la consulta básica, después las uniones entre tablas y los resúmenes por grupos, y al final la estructura y el rendimiento. La tabla reúne las dieciocho guías de esta serie sobre el lenguaje y tres temas vecinos. Las guías de SQL aparecen como próximas mientras se publican.

Si lo que busca es…	Guía	Estado
Cómo se arma una consulta y qué tipos de consulta hay	Consultas SQL	Próximamente
Qué familias de sentencias existen, una por una	Lenguajes de bases de datos	Próximamente
Cómo unir los datos de dos o más tablas	JOIN en SQL	Próximamente
Cómo contar, sumar o promediar filas	Funciones de agregación en SQL	Próximamente
Cómo usar una consulta dentro de otra	Subconsultas en SQL	Próximamente
Qué funciones trae el lenguaje para textos, fechas y números	Funciones en SQL	Próximamente
Cómo crear, cambiar o borrar tablas	Crear tablas en SQL	Próximamente
Cómo agregar, cambiar o borrar filas	INSERT, UPDATE y DELETE	Próximamente
Cómo guardar una consulta para reutilizarla como tabla	Vistas en SQL	Próximamente
Cómo guardar lógica dentro de la base de datos	Procedimientos almacenados	Próximamente
Cómo hacer que algo ocurra solo cuando cambian los datos	Triggers en SQL	Próximamente
Cómo confirmar o deshacer un grupo de cambios	Transacciones en SQL	Próximamente
Por qué una consulta es lenta y cómo leer su plan	Optimizar consultas SQL	Próximamente
Por qué el mismo código no corre igual en todos los gestores	Dialectos de SQL	Próximamente
Cómo evitar que un atacante se cuele por una consulta	Inyección SQL	Próximamente
Qué puede hacer un analista con SQL	SQL para análisis de datos	Próximamente
Ejercicios resueltos para practicar	Ejercicios de SQL	Próximamente
Por dónde empezar y en qué orden	Cómo aprender SQL desde cero	Próximamente
Qué es una base de datos y qué tipos existen	Bases de datos	Publicada
Cómo usar SQL desde un programa en Python	Python para análisis de datos	Próximamente
Qué empleos piden SQL y cuánto pagan	Rutas y carreras en datos	Próximamente

Si empieza de cero, le sugiero este orden: consultas, uniones de tablas con JOIN (juntar), funciones de agregación y luego los ejercicios. A mi juicio, con esos cuatro pasos ya responde buena parte de las preguntas que llegan a una oficina.

¿Qué cambia cuando quien pregunta sabe SQL?

Cuando la persona que tiene la pregunta también sabe SQL, la respuesta llega en minutos y no después de esperar turno en una fila de solicitudes. El área de sistemas deja de traducir preguntas ajenas y se dedica a lo que solo ella puede hacer: cuidar la base, sus permisos y su rendimiento.

Paola no necesitaba volverse ingeniera. Le bastaban un puñado de palabras del lenguaje y un permiso de solo lectura sobre una tabla, que es justo lo que las sentencias de permisos permiten dar [14].

Creo que esa brecha pesa más en las organizaciones pequeñas de Colombia. Una alcaldía pequeña, una cooperativa o una universidad regional rara vez tienen un ingeniero libre para cada pregunta. Ahí, que tres o cuatro personas de otras áreas sepan consultar marca la diferencia entre decidir con datos y decidir con lo que alguien recuerda.

El lunes de Paola se habría resuelto el jueves. ¿Cuántas de sus propias preguntas están esperando turno en una fila ajena?

Preguntas frecuentes

¿Se necesita saber programar para aprender SQL? No. Sus creadores lo diseñaron pensando también en usuarios ocasionales de bases de datos, no solo en programadores profesionales [19]. Para empezar basta con entender qué es una tabla y practicar con preguntas reales; los ciclos y las variables pueden esperar. El orden de estudio recomendado irá en la guía de cómo aprender SQL desde cero, en preparación.

¿SQL y MySQL son lo mismo? No. MySQL es un gestor de bases de datos, un programa que guarda los datos y entiende SQL. PostgreSQL, SQLite y SQL Server también lo entienden, cada uno con su dialecto [2] [1]. Qué gestor elegir y en qué se diferencian como productos es tema de la guía de bases de datos.

¿Qué es T-SQL y en qué se diferencia de PL/SQL? T-SQL, o Transact-SQL, es la versión de SQL de Microsoft: la que usan SQL Server y sus servicios de bases de datos en la nube de Azure [3]. PL/SQL es la extensión de Oracle, que la empresa compara con la parte de la norma dedicada a los módulos almacenados [2]. Las dos parten del SQL común y le agregan instrucciones propias, de modo que un programa escrito para una no siempre corre en la otra.

¿Importan las mayúsculas en SQL? En las palabras del lenguaje, no: select y SELECT significan lo mismo. En PostgreSQL 18, las palabras clave y los nombres escritos sin comillas no distinguen mayúsculas, y los nombres sin comillas se guardan en minúsculas [10]. Un nombre entre comillas dobles, en cambio, sí las distingue [10]. La norma pide pasar esos nombres a mayúsculas, y PostgreSQL reconoce que en ese punto se aparta de ella [10].

¿Una consulta SQL puede borrar datos por accidente? Una consulta de lectura, no. Oracle describe SELECT como una forma limitada de manipulación que solo puede acceder a los datos [15]. El riesgo está en otras órdenes, como DELETE (borrar): sin una condición WHERE, borra todas las filas de la tabla [24]. Hay además una trampa menos conocida. En PostgreSQL, EXPLAIN ANALYZE (explicar y analizar) sí ejecuta la sentencia para medir tiempos reales, y sus efectos ocurren como siempre [16]. La documentación recomienda envolverla en una transacción y deshacerla al final [16].

Referencias

Las citas en otro idioma son traducción propia.

1. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, apéndice D «SQL Conformance» — nombre formal de la norma, ISO/IEC 9075 «Database Language SQL»; revisión más reciente en 2023 (SQL:2023) y versiones previas desde SQL-92; cada versión reemplaza a la anterior y declarar conformidad con versiones viejas no tiene valor oficial; muchas funciones del estándar se soportan con sintaxis o funcionamiento ligeramente distintos; tres niveles de conformidad de SQL-92 (Entry, Intermediate, Full); lista de las partes de la norma, incluida la parte 4, Persistent Stored Modules (SQL/PSM); PostgreSQL cumple al menos 170 de las 177 características obligatorias del núcleo de SQL:2023 y ningún gestor actual afirma cumplir el núcleo completo. PostgreSQL: Documentation 18, SQL Conformance — Consultada: 2026-10-09.
2. Oracle. SQL Language Reference, sección «SQL Standards» (documentación de Oracle AI Database, versión 23) — ANSI e ISO/IEC aceptan SQL como lenguaje estándar de las bases relacionales; las normas publicadas a la vez por ambos son técnicamente idénticas; las sentencias de control de flujo no formaban parte de SQL al principio y hoy están en ISO/IEC 9075-4 (SQL/PSM); PL/SQL es parecido a PSM; «Technically speaking, SQL is a data sublanguage»; todas las sentencias son instrucciones para la base de datos y en eso SQL se diferencia de lenguajes de propósito general como C; lo que el lenguaje permite hacer; todos los gestores relacionales importantes soportan SQL y las habilidades se transfieren entre ellos. Oracle: SQL Language Reference, SQL Standards — Consultada: 2026-10-09.
3. Microsoft. Transact-SQL Reference (Database Engine), Microsoft Learn (fecha del artículo: 26 de enero de 2026) — T-SQL es central para los productos y servicios SQL de Microsoft; todas las herramientas y aplicaciones que se comunican con una base de SQL Server lo hacen enviando comandos T-SQL; aplica a SQL Server y a los servicios Azure SQL. Microsoft Learn: Transact-SQL Reference — Consultada: 2026-10-09.
4. IBM. The relational database (página de historia de la empresa) — Edgar F. Codd, matemático formado en Oxford, en el laboratorio de investigación de IBM en San José; su artículo de 1970; en 1973 un grupo de programadores emprendió System R, una implementación a escala industrial; Chamberlin, coinventor con Raymond Boyce de Structured Query Language (SQL); Chamberlin y Boyce desarrollaron SQL y sistemas para traducir automáticamente consultas de alto nivel en planes de ejecución eficientes. IBM: The relational database — Consultada: 2026-10-09.
5. Oracle. SQL Language Reference, sección «History of SQL» (documentación de Oracle AI Database, versión 23) — artículo de Codd de junio de 1970 en Communications of the ACM; su modelo, aceptado como definitivo para los gestores relacionales; IBM desarrolló SEQUEL para usar el modelo de Codd; SEQUEL se convirtió en SQL, que todavía se pronuncia «sequel»; en 1979 Relational Software, hoy Oracle, presentó la que la empresa llama la primera implementación comercial de SQL. Oracle: SQL Language Reference, History of SQL — Consultada: 2026-10-09.
6. Departamento Administrativo Nacional de Estadística (DANE). DIVIPOLA – Códigos municipios, conjunto de datos en datos.gov.co (licencia CC BY-SA 4.0; actualización a corte 30 de diciembre de 2024, filas actualizadas el 24 de enero de 2025) — columnas cod_dpto, dpto, cod_mpio, nom_mpio, tipo_municipio, longitud y latitud; 1.122 filas en total, 87 de ellas del departamento de Santander y todas de tipo «Municipio» (conteo hecho con la API del portal); 68001 = Bucaramanga. datos.gov.co: DIVIPOLA – Códigos municipios — Consultada: 2026-10-09.
7. SQLite. Query Planning (página actualizada el 22 de marzo de 2026) — «When programming in SQL you tell the system what you want to compute, not how to compute it»; SQL es un lenguaje declarativo, no procedimental; la tarea de decidir el cómo se delega al planificador de consultas; para una sentencia puede haber cientos, miles o millones de algoritmos que dan la respuesta correcta, unos más rápidos que otros. SQLite: Query Planning — Consultada: 2026-10-09.
8. Microsoft. Query processing architecture guide, Microsoft Learn — una sentencia SELECT no es procedimental y no indica los pasos exactos; el servidor la analiza para encontrar la forma más eficiente de extraer los datos, lo que se llama optimizar; las entradas del optimizador son la consulta, el esquema y las estadísticas; su salida es el plan de ejecución. Microsoft Learn: Query processing architecture guide — Consultada: 2026-10-09.
9. SQLite. How SQLite Works (página actualizada el 31 de mayo de 2025) — unas pocas líneas de SQL pueden reemplazar cientos o miles de líneas de código procedimental; SQLite traduce el texto SQL a bytecode que corre un intérprete; ese bytecode se llama sentencia preparada, y la traducción es análoga a compilar un programa; SQL es un lenguaje de programación declarativo, distinto de C, JavaScript, Python o Go, que son imperativos. SQLite: How SQLite Works — Consultada: 2026-10-09.
10. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, sección 4.1 «Lexical Structure» — la entrada SQL es una secuencia de comandos formados por tokens y terminados en punto y coma; las palabras clave y los identificadores sin comillas no distinguen mayúsculas; un identificador entre comillas sí las distingue y los nombres sin comillas se pasan a minúsculas, lo que PostgreSQL reconoce incompatible con la norma, que pide mayúsculas. PostgreSQL: Documentation 18, Lexical Structure — Consultada: 2026-10-09.
11. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, sección 51.1 «The Path of a Query» — las cinco etapas de una consulta: conexión, análisis (parser y árbol de consulta), sistema de reescritura (reglas, vistas), planificador/optimizador (todos los caminos posibles, costo estimado, el más barato; ejemplo del recorrido secuencial frente al índice) y ejecutor. PostgreSQL: Documentation 18, The Path of a Query — Consultada: 2026-10-09.
12. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, sección 14.1 «Using EXPLAIN» — PostgreSQL elabora un plan para cada consulta y EXPLAIN muestra el plan que crea el planificador; el plan es un árbol de nodos y la salida tiene una línea por nodo con estimaciones de costo; ejemplo de Seq Scan con la cláusula WHERE aplicada como condición «Filter» que revisa cada fila. PostgreSQL: Documentation 18, Using EXPLAIN — Consultada: 2026-10-09.
13. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, sección 41.1 «Overview» de PL/pgSQL — PL/pgSQL es un lenguaje procedimental para PostgreSQL; SQL es portátil y fácil de aprender, pero cada sentencia debe ejecutarla el servidor por separado; PL/pgSQL agrupa un bloque de cálculos y una serie de consultas dentro del servidor y ahorra comunicación entre cliente y servidor. PostgreSQL: Documentation 18, PL/pgSQL Overview — Consultada: 2026-10-09.
14. Microsoft. Transact-SQL statements, Microsoft Learn — categorías de sentencias, entre ellas definición de datos (ALTER, CREATE, DROP, TRUNCATE TABLE…), manipulación de datos (BULK INSERT, DELETE, INSERT, SELECT, UPDATE, MERGE) y sentencias de permisos, que determinan qué usuarios pueden acceder a los datos y realizar operaciones. Microsoft Learn: Transact-SQL statements — Consultada: 2026-10-09.
15. Oracle. SQL Language Reference, sección «Types of SQL Statements» (documentación de Oracle AI Database, versión 23) — categorías: DDL, DML, control de transacciones, control de sesión, control de sistema y SQL incrustado; conceder y revocar privilegios figura entre las tareas del DDL; SELECT es «a limited form of DML statement in that it can only access data in the database»; sentencias de control de transacciones: COMMIT, ROLLBACK, SAVEPOINT, SET TRANSACTION y SET CONSTRAINT. Oracle: SQL Language Reference, Types of SQL Statements — Consultada: 2026-10-09.
16. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, referencia de la orden EXPLAIN — con la opción ANALYZE la sentencia se ejecuta de verdad y sus demás efectos ocurren como siempre; para analizar un INSERT, UPDATE o DELETE sin afectar los datos se recomienda envolverlo entre BEGIN y ROLLBACK. PostgreSQL: Documentation 18, EXPLAIN — Consultada: 2026-10-09.
17. SQLite. SQL Features That SQLite Does Not Implement (página actualizada el 18 de abril de 2022) — GRANT y REVOKE no están implementados porque SQLite lee y escribe un archivo común y los únicos permisos aplicables son los del sistema operativo. SQLite: SQL Features That SQLite Does Not Implement — Consultada: 2026-10-09.
18. Codd, Edgar F. A Relational Model of Data for Large Shared Data Banks, Communications of the ACM, vol. 13, n.º 6, junio de 1970, pp. 377-387 — artículo que propone el modelo relacional (se cita en paráfrasis; no se entrecomilla). ACM: DOI 10.1145/362384.362685 — Consultada: 2026-10-09.
19. Chamberlin, Donald D. y Boyce, Raymond F. SEQUEL: A Structured English Query Language, taller ACM SIGFIDET sobre descripción, acceso y control de datos, pp. 249-264 — presenta SEQUEL, lenguaje de consulta para bases de datos relacionales dirigido tanto al programador profesional como al usuario ocasional, construido con plantillas de palabras en inglés que reflejan cómo la gente usa las tablas para obtener información. El registro de IBM Research lo fecha el 1 de mayo de 1974; los metadatos del DOI rotulan las actas con 1976 (se usa la fecha de IBM Research, institución de los autores). ACM: DOI 10.1145/800296.811515 · IBM Research: ficha de la publicación — Consultada: 2026-10-09.
20. National Bureau of Standards. Federal Information Processing Standards Publication 127: Database Language SQL, que reproduce la norma estadounidense ANSI X3.135-1986 (copia digitalizada en Internet Archive) — «American National Standard for Information Systems – Database Language – SQL», ANSI X3.135-1986, aprobada el 16 de octubre de 1986. Internet Archive: FIPS PUB 127, Database Language SQL — Consultada: 2026-10-09.
21. Organización Internacional de Normalización (ISO). ISO 9075:1987 Information processing systems — Database language — SQL (ficha del catálogo) — edición 1, publicada en junio de 1987; retirada el 19 de abril de 1989 al aparecer ISO/IEC 9075:1989. ISO: ficha de ISO 9075:1987 — Consultada: 2026-10-09.
22. Organización Internacional de Normalización (ISO). ISO/IEC 9075-1:2023 Information technology — Database languages SQL — Part 1: Framework (SQL/Framework) (ficha del catálogo) — edición 6, publicada en junio de 2023, 74 páginas, comité ISO/IEC JTC 1/SC 32; estado: norma por revisar (etapa 90.92, desde el 22 de junio de 2025). ISO: ficha de ISO/IEC 9075-1:2023 — Consultada: 2026-10-09.
23. Stack Overflow. 2026 Developer Survey, capítulo «Technology» y nota metodológica — SQL, usado por el 58,4 % de quienes respondieron la pregunta de lenguajes, segundo detrás de JavaScript (62,0 %); encuesta recogida del 23 de junio al 5 de agosto de 2026, con 30.903 respuestas de 169 países, difundida por stackoverflow.com, su blog y su lista de correo. Fuente de Nivel B (informe de industria, muestra autoseleccionada). Stack Overflow: 2026 Developer Survey, Technology · Stack Overflow: 2026 Developer Survey, Methodology — Consultada: 2026-10-09.
24. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, referencia de la orden DELETE — DELETE borra las filas que cumplen la cláusula WHERE; si la cláusula falta, el efecto es borrar todas las filas de la tabla. PostgreSQL: Documentation 18, DELETE — Consultada: 2026-10-09.

Cómo investigamos esta página

• Pregunta que responde: Qué es SQL, para qué sirve, cómo convierte el gestor una consulta en un plan de ejecución, si es un lenguaje de programación y de dónde viene su norma.
• Fuentes: identificadas 38 → incluidas 25 (documentación oficial de PostgreSQL, Oracle, Microsoft y SQLite, registros ISO y ANSI, artículos por DOI y datos del DANE).
• Criterios de inclusión: solo documentación oficial, registros de la norma, textos académicos y datos públicos leídos hoy; una encuesta de industria como única fuente secundaria declarada.
• Fecha de corte de los datos: 2026-10-09