Programación y habilidades digitales bases de datos SQL PostgreSQL SQLite aprender SQL bases de datos para principiantes

Cómo aprender bases de datos sin experiencia: ruta práctica

Aprende tablas, claves, consultas, relaciones y transacciones con una práctica SQL verificable y diferencias claras entre SQLite y PostgreSQL.

Estudiante aprendiendo tablas y relaciones de una base de datos en una laptop.
· Crezendo

Puedes aprender bases de datos sin experiencia previa en programación, pero el objetivo no es memorizar comandos. Es convertir una pregunta en un modelo, proteger la calidad de los datos, escribir una consulta y comprobar que el resultado significa lo que crees.

Esta guía propone una práctica pequeña y reproducible. No promete empleo, certificación, dominio profesional ni aprendizaje dentro de un plazo. Avanzas cuando puedes explicar una decisión, ejecutar el SQL y comparar el resultado con una expectativa escrita.

Qué significa aprender bases de datos

Una base de datos no es solo una tabla grande. Es un sistema para representar hechos y aplicar reglas mientras varias operaciones leen o cambian información. Una persona principiante debería poder:

  • describir qué entidad representa cada tabla;
  • distinguir una fila de una columna y un valor ausente de un valor vacío;
  • elegir una clave que identifique cada registro;
  • relacionar tablas sin repetir información innecesariamente;
  • exigir datos válidos con restricciones;
  • formular preguntas con SQL y verificar el resultado;
  • agrupar cambios que deben confirmarse o revertirse juntos;
  • conservar el esquema, datos de prueba y resultados esperados.

La sintaxis es una herramienta para demostrar estas capacidades. Copiar una consulta que devuelve filas no basta si no puedes explicar por qué esas filas aparecen o cuáles faltan.

Construye primero el modelo mental

Usaremos un ejemplo ficticio de clientes y pedidos. No emplees datos reales de clientes, credenciales, historiales médicos, información bancaria ni exportaciones de producción para aprender.

Tabla, fila y columna

Una tabla representa un tipo de entidad o hecho. Cada fila es una ocurrencia y cada columna describe una propiedad. En customers, una fila representa a una persona ficticia; en orders, una fila representa un pedido ficticio.

Clave primaria

La clave primaria identifica una fila dentro de su tabla. customer_id=1 debe señalar un solo cliente, aunque dos personas compartan nombre. No elijas como clave un dato que puede cambiar sin entender las consecuencias.

Clave foránea

Una clave foránea exige que una referencia tenga un destino válido. orders.customer_id conecta cada pedido con una fila de customers. Esta regla evita pedidos huérfanos cuando el motor la aplica.

Restricciones y valores nulos

NOT NULL, UNIQUE, CHECK, claves primarias y claves foráneas convierten parte del significado del dominio en reglas verificables. NULL expresa ausencia o desconocimiento según el modelo; no equivale automáticamente a cero ni a texto vacío.

SQL es un estándar, pero también tiene dialectos

ISO/IEC 9075-1:2023 define el marco conceptual usado por la serie de estándares SQL. Eso no implica que todas las implementaciones acepten los mismos tipos, funciones, comillas o extensiones. La propia documentación de conformidad SQL de PostgreSQL registra diferencias y recomienda usar la documentación del motor como referencia precisa.

Aprende primero ideas transferibles —tablas, claves, SELECT, filtros, joins, agregación y transacciones— y anota junto a cada ejercicio:

  • motor y versión;
  • sentencia ejecutada;
  • resultado esperado y real;
  • diferencia de dialecto encontrada;
  • fuente oficial consultada.

Así evitas presentar una conducta de un motor como una regla universal.

¿Quieres revisar tu punto de partida o una ruta para un equipo? Consulta a Crezendo indicando objetivo, experiencia actual, motor disponible y modalidad de práctica. Primero se confirma si existe una opción vigente de orientación, capacitación o apoyo; el contacto no promete taller, cupo, precio, certificado, plazo ni resultado.

Elige un entorno según lo que quieres observar

No hay un motor “mejor” para toda persona principiante. Hay entornos que exponen problemas distintos.

SQLite para una práctica local y desechable

SQLite es embebido: no necesita un proceso servidor separado. Su inicio rápido oficial y la documentación de la CLI muestran cómo abrir un archivo y ejecutar SQL. Es útil para concentrarse en esquema, datos pequeños y consultas.

SQLite usa tipado flexible y tiene particularidades documentadas. Sus claves foráneas deben habilitarse por conexión con PRAGMA foreign_keys = ON, según la documentación oficial. No asumas que una declaración de tipo o restricción se comportará igual que en otro motor.

PostgreSQL para aprender un sistema cliente-servidor

El tutorial actual de PostgreSQL introduce conceptos relacionales y SQL sin exigir experiencia particular en Unix o programación. Además de consultas, permite observar conexión, roles, esquemas, concurrencia y administración separada del cliente.

Usa una instalación de práctica o un entorno autorizado, nunca una base de producción. Registra versión, usuario, base y permisos; no trabajes como superusuario cuando una cuenta limitada sea suficiente.

Prepara un laboratorio seguro

Crea una base desechable llamada, por ejemplo, sql_lab. Guarda el SQL en archivos de texto para reconstruirla. Antes de empezar:

  1. confirma que no apunta a producción;
  2. usa únicamente datos ficticios;
  3. activa y verifica claves foráneas si usas SQLite;
  4. conserva por separado schema.sql, seed.sql y queries.sql;
  5. escribe resultados esperados antes de ejecutar;
  6. prueba cómo eliminar o reconstruir solo el laboratorio;
  7. evita pegar contraseñas o cadenas de conexión en capturas y documentos.

En la CLI de SQLite, sqlite3 sql_lab.db crea o abre el archivo indicado. En PostgreSQL, sigue la sección de acceso del tutorial oficial y verifica visualmente el nombre de la base antes de ejecutar una sentencia que modifique datos.

Crea dos tablas con reglas explícitas

Este esquema usa identificadores proporcionados manualmente para mantener el ejercicio sencillo entre SQLite y PostgreSQL:

CREATE TABLE customers (
  customer_id INTEGER PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  city VARCHAR(80) NOT NULL
);

CREATE TABLE orders (
  order_id INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL,
  order_date DATE NOT NULL,
  amount DECIMAL(10,2) NOT NULL CHECK (amount >= 0),
  FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);

La documentación de definición de datos de PostgreSQL y la de CREATE TABLE de SQLite explican las restricciones disponibles. Revisa también sus diferencias de tipos: DATE y DECIMAL no tienen idéntica semántica de almacenamiento y validación en ambos motores.

Antes de cargar datos, predice qué ocurriría si:

  • dos clientes usan el mismo customer_id;
  • un pedido no incluye amount;
  • amount es negativo;
  • un pedido referencia un cliente inexistente.

Después comprueba cada caso en tu entorno y conserva el mensaje de error. El texto exacto puede variar; lo importante es qué regla rechazó la escritura.

Carga un conjunto pequeño con resultado conocido

INSERT INTO customers (customer_id, name, city) VALUES
  (1, 'Ana', 'Panamá'),
  (2, 'Luis', 'Colón'),
  (3, 'Marta', 'Panamá');

INSERT INTO orders (order_id, customer_id, order_date, amount) VALUES
  (101, 1, '2026-08-01', 25.50),
  (102, 1, '2026-08-03', 10.00),
  (103, 2, '2026-08-03', 20.00);

Ahora puedes escribir expectativas sin consultar la base: hay tres clientes, tres pedidos, Ana tiene dos pedidos por un total de 35.50, Luis uno por 20.00 y Marta ninguno. Esa hoja de respuestas permite detectar una consulta incorrecta aunque produzca una tabla convincente.

No confundas los montos ficticios con una política contable. En un sistema real, moneda, precisión, redondeo y auditoría necesitan decisiones explícitas.

Consulta una sola tabla con intención

Empieza nombrando la pregunta en lenguaje natural: “¿Qué clientes ficticios están en Panamá y cómo se ordenan por nombre?”

SELECT customer_id, name
FROM customers
WHERE city = 'Panamá'
ORDER BY name;

Resultado esperado:

customer_id name
1 Ana
3 Marta

SELECT elige columnas, FROM indica la fuente, WHERE filtra y ORDER BY hace explícito el orden. Sin ORDER BY, no debes depender del orden observado en una ejecución.

Practica variaciones y predice cada resultado:

  • cambia la ciudad a un valor ausente;
  • ordena en dirección descendente;
  • añade city a la proyección;
  • filtra por una lista de ciudades;
  • cuenta las filas resultantes.

Para ampliar la sintaxis sin duplicar esta ruta, modifica las consultas del laboratorio: agrega condiciones, agrupaciones, subconsultas cuando sean necesarias y compara siempre el resultado con una expectativa escrita.

Relaciona tablas sin perder a quien no tiene pedidos

La pregunta ahora es: “¿Cuántos pedidos y qué monto total tiene cada cliente, incluidos quienes no tienen pedidos?”

SELECT c.name,
       COUNT(o.order_id) AS order_count,
       COALESCE(SUM(o.amount), 0) AS total_amount
FROM customers AS c
LEFT JOIN orders AS o ON o.customer_id = c.customer_id
GROUP BY c.customer_id, c.name
ORDER BY c.customer_id;

Resultado verificado:

name order_count total_amount
Ana 2 35.5
Luis 1 20
Marta 0 0

El LEFT JOIN conserva a Marta aunque no exista una fila relacionada. COUNT(o.order_id) cuenta pedidos, no filas del lado izquierdo. SUM sobre un conjunto sin valores produce NULL; COALESCE lo transforma en cero para esta salida concreta. Antes de usar esa decisión en otro dominio, confirma si “sin registros” y cero significan lo mismo.

Compara con INNER JOIN y explica por qué Marta desaparece. Después elimina COALESCE y observa el valor resultante. Aprender consiste en poder anticipar esas diferencias.

Comprueba que las restricciones hacen trabajo real

Con claves foráneas activas, esta escritura debe fallar porque no existe el cliente 999:

INSERT INTO orders (order_id, customer_id, order_date, amount)
VALUES (104, 999, '2026-08-04', 5.00);

Si SQLite la acepta, revisa PRAGMA foreign_keys; en esa conexión. Una declaración que no se aplica no protege datos. Prueba también un monto negativo y una clave repetida, siempre dentro del laboratorio.

No conviertas cada regla en código de aplicación. Cuando la base puede garantizar una propiedad estructural, una restricción permite que todos los clientes y scripts respeten la misma frontera.

Usa transacciones para practicar sin conservar el cambio

La documentación de transacciones de SQLite y el tutorial de PostgreSQL explican BEGIN, COMMIT y ROLLBACK. Ejecuta:

BEGIN;

UPDATE orders
SET amount = amount + 5
WHERE order_id = 103;

SELECT amount
FROM orders
WHERE order_id = 103;

ROLLBACK;

SELECT amount
FROM orders
WHERE order_id = 103;

En la práctica verificada, la primera lectura mostró 25 y la lectura posterior a ROLLBACK volvió a 20. Repite hasta poder explicar qué cambio fue visible y por qué no persistió.

Una transacción no sustituye copias de seguridad ni vuelve inocua cualquier sentencia. Verifica la base, usa datos desechables y filtra un UPDATE o DELETE antes con un SELECT equivalente.

Avanza por evidencias, no por calendario

Completa cada etapa cuando puedas producir la evidencia indicada:

Etapa Práctica Evidencia de comprensión
Modelo entidades, atributos y relaciones diagrama sencillo y decisiones explicadas
Integridad claves y restricciones escrituras inválidas rechazadas de forma prevista
Lectura proyección, filtro y orden resultados comparados con una tabla esperada
Relaciones joins y agregación explicación de filas conservadas, descartadas y agrupadas
Cambio insert, update y delete modificaciones acotadas y verificadas
Transacción commit y rollback estado antes, durante y después documentado
Rendimiento índices y planes plan leído antes y después con datos apropiados
Portabilidad dos motores diferencias de tipo, sintaxis y comportamiento registradas

No saltes al tema siguiente solo porque una consulta ejecutó. Cambia datos, prueba casos límite y explica el resultado sin mirar una solución.

Aprende a depurar una consulta

Cuando algo falla, evita cambiar muchas cosas a la vez:

  1. copia el mensaje exacto y conserva la sentencia;
  2. confirma motor, versión, base, esquema y usuario;
  3. reduce la consulta hasta el fragmento mínimo que falla;
  4. inspecciona nombres y tipos desde el catálogo del motor;
  5. prueba el filtro antes del join y el join antes de la agregación;
  6. cuenta filas en cada etapa;
  7. trata NULL de forma explícita;
  8. consulta la documentación de esa versión;
  9. registra causa y corrección, no solo la consulta final.

Una consulta sintácticamente válida todavía puede responder otra pregunta. Usa ejemplos donde conozcas la respuesta y revisa duplicados, filas ausentes y límites.

Estudia índices después de entender la consulta

Un índice no repara un modelo incorrecto ni garantiza rapidez. Empieza con datos suficientes para observar una diferencia y una consulta repetible. PostgreSQL documenta EXPLAIN como herramienta para ver el plan elegido.

Lee primero un EXPLAIN sin ejecutar efectos. EXPLAIN ANALYZE sí ejecuta la sentencia; sobre escrituras puede cambiar datos. En un laboratorio controlado, registra plan, estimaciones, filas reales y cambio realizado. No extrapoles el comportamiento de tres filas a una carga grande.

Prueba un índice relacionado con un filtro o join frecuente, vuelve a observar el plan y explica el costo de mantenerlo durante escrituras. Si no puedes formular esa explicación, todavía no necesitas añadir muchos índices.

Conserva un laboratorio reproducible

Organiza el ejercicio como material de aprendizaje, no como prueba de experiencia profesional:

sql-lab/
├── README.md
├── versions.md
├── schema.sql
├── seed.sql
├── queries.sql
└── expected-results.md

El README explica la pregunta y el orden de ejecución. versions.md registra motor y versión. El esquema y los datos permiten reconstruir. Cada consulta incluye una expectativa y una nota sobre diferencias. Elimina secretos, rutas privadas y datos personales antes de compartir.

Cuando el laboratorio sea repetible, amplíalo con un dominio que conozcas y datos ficticios que permitan verificar las respuestas. Si tu objetivo es visualización, revisa cómo aprender Power BI desde cero. Si necesitas automatizar acceso a datos, complementa con fundamentos de programación.

Errores frecuentes al comenzar

  • practicar con datos reales o sensibles;
  • confundir hoja de cálculo, base de datos y gestor de base de datos;
  • memorizar sintaxis sin escribir resultados esperados;
  • usar SELECT * como salida permanente sin justificar columnas;
  • asumir un orden sin ORDER BY;
  • olvidar cómo afectan los valores NULL;
  • unir tablas sin revisar cardinalidad y duplicados;
  • declarar claves foráneas en SQLite sin verificar que estén activas;
  • ejecutar UPDATE o DELETE sin validar el filtro;
  • crear índices antes de medir un plan;
  • copiar sintaxis de otro motor sin revisar el dialecto;
  • tratar un laboratorio pequeño como evidencia de dominio profesional.

Preguntas frecuentes

¿Necesito saber programación?

No para comenzar el tutorial oficial de PostgreSQL o este laboratorio. Sí necesitas manejar archivos, una terminal o cliente y mensajes de error básicos. La programación se vuelve relevante al conectar una aplicación, automatizar pruebas o gestionar transacciones desde código.

¿Empiezo con SQLite o PostgreSQL?

SQLite reduce componentes y permite practicar localmente; PostgreSQL expone arquitectura cliente-servidor, roles y mayor administración. Elige según el concepto que quieras observar y registra diferencias. Ninguno es universalmente mejor.

¿Cómo sé que entendí una consulta?

Puedes predecir el resultado, explicar cada cláusula, detectar filas faltantes o duplicadas, modificar los datos de prueba y anticipar cómo cambia la salida.

¿Cuánto tiempo toma aprender SQL?

No existe un plazo universal. El punto de partida, la profundidad y la práctica cambian el proceso. Usa las evidencias de la ruta en lugar de una fecha o número de horas prometido.

¿Este laboratorio entrega un certificado?

No. Es una práctica reproducible para comprobar conceptos. Un certificado, examen o requisito institucional tiene condiciones separadas que deben confirmarse con su emisor.

¿Cómo practico sin experiencia ni datos reales?

Usa datos ficticios pequeños con respuestas conocidas, provoca errores controlados y reconstruye la base desde archivos SQL. No necesitas información laboral o de producción.

¿SQL funciona igual en todos los motores?

No. Comparte una base estandarizada, pero tipos, funciones, extensiones y comportamiento varían. Consulta siempre la documentación del motor y versión usados.

¿Crezendo ofrece capacitación en bases de datos?

Puedes consultar para confirmar qué opción existe en ese momento y si encaja con tu objetivo. Este artículo no anuncia curso, taller, mentoría, equipo, cupo, precio, modalidad, certificado o disponibilidad permanente.

Empieza con una pregunta que puedas verificar

Elige un dominio ficticio pequeño, escribe cinco preguntas y construye solo las tablas necesarias para responderlas. Carga datos con respuestas conocidas, prueba restricciones, ejecuta consultas y revierte un cambio. Tu progreso se ve en la explicación y la reproducción, no en cuántos comandos copiaste.

Si quieres ordenar una ruta individual o para un equipo, contacta a Crezendo con el objetivo, experiencia actual, motor disponible y muestra del ejercicio. La conversación sirve para confirmar si hay una opción vigente de orientación, capacitación o apoyo; no garantiza taller, cupo, precio, modalidad, certificado, plazo ni resultado.

¿Tu empresa necesita resolver este reto?

Crezendo diseña talleres a medida para empresas, ONGs y organismos de gobierno. Mira todo lo que podemos hacer por tu organización o cuéntanos tu necesidad para recibir una propuesta y cotización.

Solicitar propuesta y cotización Ver talleres para empresas