Ya sabes qué es SQL y cómo se escribe. Toca ahora entender sobre qué actúa: la estructura donde viven los datos. En esta lección desmontaremos la jerarquía completa —servidor, base de datos, esquema, tabla, fila, columna—, veremos por qué la analogía con una hoja de cálculo ayuda al principio pero se rompe enseguida, y recorreremos en detalle el catálogo de tipos de datos de PostgreSQL. Ese último punto es más importante de lo que parece: elegir mal un tipo es un error que se paga durante años, y el caso del dinero guardado en coma flotante es el ejemplo canónico de por qué. Terminaremos aprendiendo a inspeccionar tablas que ya existen, una habilidad que necesitarás cada vez que te enfrentes a una base de datos ajena.

1. La jerarquía: servidor, base de datos, esquema, tabla
2. Tablas, filas y columnas
3. La analogía de la hoja de cálculo (y dónde se rompe)
4. Tipos de datos numéricos
5. Por qué el dinero nunca va en coma flotante
6. Tipos de texto
7. Tipos de fecha y hora
8. Booleanos, UUID y JSONB
9. NULL: la ausencia de valor
10. Equivalencias entre PostgreSQL, MySQL y SQLite
11. Cómo inspeccionar tablas existentes
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

En PostgreSQL los objetos se organizan en cuatro niveles:

Dos consecuencias prácticas de esta jerarquía:

1. No puedes consultar dos bases de datos a la vez. Si tiendaverde y pruebas_sql viven en el mismo servidor, una consulta no puede combinarlas directamente (harían falta extensiones como dblink o postgres_fdw). En MySQL, en cambio, sí es habitual escribir SELECT ... FROM otra_base.tabla, porque allí "base de datos" y "esquema" son casi sinónimos.
2. Los esquemas sí se combinan libremente. Dentro de tiendaverde podrías tener un esquema ventas y otro analitica y consultarlos juntos sin problema.

Toda base de datos PostgreSQL nace con un esquema llamado public. Si creas una tabla sin indicar esquema, va a parar allí, y si la consultas sin prefijo se busca allí. Estas dos sentencias son equivalentes en nuestra configuración:

El orden de búsqueda lo determina el parámetro search_path:

Significa: "busca primero un esquema que se llame como el usuario conectado; si no existe, busca en public". Los esquemas sirven para organizar bases grandes (separar por área funcional, por cliente, por entorno) y para evitar colisiones de nombres. Todo TiendaVerde vive en public, así que no volveremos a preocuparnos por esto.

Una tabla es una colección de filas que comparten la misma estructura. Cada tabla se define por:

• Un nombre (productos).
• Un conjunto ordenado de columnas, cada una con nombre y tipo de dato.
• Opcionalmente, restricciones que limitan qué valores son válidos (módulo 5).

Una vista simplificada de productos:

Terminología formal frente a la coloquial:

Tres propiedades fundamentales que conviene grabar desde el principio:

1. Todas las filas tienen las mismas columnas. No existe una fila "con un campo extra". Si un dato no aplica, se guarda NULL.
2. Cada columna tiene un único tipo. No puedes guardar 'mañana' en una columna DATE.
3. Las filas no tienen orden intrínseco. Una tabla es un conjunto. Si no pides ORDER BY explícitamente, el motor puede devolvértelas en cualquier orden, y ese orden puede cambiar mañana. Es un error clásico confiar en el "orden natural".

Al principio ayuda pensar en una tabla como una hoja de Excel: la primera fila son los encabezados (columnas) y las siguientes, los datos (filas). La analogía funciona... hasta cierto punto.

La diferencia conceptual más profunda es la tipificación estricta. En Excel, una columna de precios puede tener 12,50, 12.50, "12,50 €" y doce con cincuenta, y nadie te avisa hasta que la suma da mal. En PostgreSQL, si la columna es NUMERIC(10,2), el motor rechaza cualquier cosa que no sea un número:

Ese error, que puede parecer una molestia, es exactamente el valor que aporta una base de datos: los datos incorrectos no llegan a entrar.

Sobre NUMERIC(p,s):

• p (precisión) es el número total de dígitos.
• s (escala) es cuántos de esos dígitos van tras la coma.
• NUMERIC(10,2) admite hasta 99 999 999,99 → ocho dígitos enteros y dos decimales.

En TiendaVerde usamos NUMERIC(10,2) para precio, coste, gastos_envio, precio_unitario, importe y salario, y NUMERIC(4,2) para descuento (una fracción entre 0 y 1, con dos decimales).

Nota sobre SERIAL: no es un tipo real, sino un atajo que crea un INTEGER más una secuencia que lo autoincrementa. Desde PostgreSQL 10 la forma recomendada por el estándar es GENERATED BY DEFAULT AS IDENTITY, que es la que usa el script del curso. Lo verás con detalle en el módulo 5.

REAL y DOUBLE PRECISION almacenan los números en coma flotante binaria (estándar IEEE 754). El problema es que muchos decimales que en base 10 son exactos, en base 2 son periódicos: 0,1 en binario es infinito, igual que 1/3 lo es en decimal. El ordenador guarda una aproximación, y esos errores minúsculos se acumulan.

Compruébalo:

Y el caso que te arruinaría un cierre contable:

Llevado a TiendaVerde: si guardáramos precio como REAL y sumáramos las 47 líneas de pedido de la base de datos, el total podría salir 143,20999999998 en lugar de 143,21. Multiplícalo por miles de pedidos al mes y tendrás un descuadre contable imposible de justificar.

Regla sin excepciones: dinero → NUMERIC. Nunca FLOAT, REAL ni DOUBLE PRECISION. La penalización de velocidad es irrelevante comparada con un céntimo perdido.

Existe además el tipo MONEY en PostgreSQL, pero no se recomienda: depende de la configuración regional del servidor y no admite bien varias divisas. Usa NUMERIC.

Una particularidad de PostgreSQL que sorprende a quien viene de otros motores: TEXT y VARCHAR tienen exactamente el mismo rendimiento. Internamente son el mismo tipo; VARCHAR(n) solo añade una comprobación de longitud. No hay ninguna ventaja de velocidad en poner un límite.

Entonces, ¿cuándo poner VARCHAR(n)? Cuando el límite signifique algo:

• pais VARCHAR(60): nombre de país, un límite razonable.
• email VARCHAR(120): hay un máximo práctico conocido.
• descripcion TEXT: no sabemos cuánto escribirá nadie.
• comentario TEXT: una reseña puede ser larga.

Evita CHAR(n). Rellena con espacios a la derecha y provoca comparaciones sorprendentes:

El valor se guarda como 'ES ' pero al compararlo se ignoran los espacios finales, lo que genera confusión constante al exportar o concatenar.

Nota de dialecto: en MySQL sí hay diferencias de rendimiento y almacenamiento entre CHAR, VARCHAR y TEXT (los TEXT se almacenan fuera de la fila y no admiten valor por defecto). Lo que aquí es indiferente, allí no lo es.

La distinción entre TIMESTAMP y TIMESTAMPTZ es la que más problemas causa en producción:

• TIMESTAMP guarda literalmente lo que le das. Si un cliente francés y otro español registran "18:30", se guardan igual aunque sean momentos distintos.
• TIMESTAMPTZ convierte a UTC al guardar y a la zona del cliente al leer. Representa un instante real del tiempo.

Regla práctica: si el momento tiene relevancia real (cuándo ocurrió algo), usa TIMESTAMPTZ. Si es una fecha de calendario sin hora (fecha de un pedido, fecha de nacimiento), usa DATE. TiendaVerde usa DATE en todas sus fechas porque son fechas de calendario, no instantes.

Dialecto: MySQL tiene DATETIME (sin zona) y TIMESTAMP (con conversión a UTC, pero limitado hasta 2038). SQLite no tiene tipo de fecha: guarda texto ISO, números o julian days, y las funciones de fecha operan sobre esas representaciones.

Guarda TRUE, FALSE o NULL. Ocupa 1 byte. En TiendaVerde lo usan productos.activo y proveedores.activo.

Ese NULL tiene sentido de negocio: "activo = TRUE" es un producto en venta, "FALSE" uno descatalogado, y NULL significaría "todavía no lo hemos decidido". Por eso los booleanos en SQL tienen tres estados, no dos.

Un identificador universal de 128 bits, del estilo a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11. Ocupa 16 bytes.

TiendaVerde usa INTEGER para sus id porque es una base pequeña, didáctica y donde poder escribir WHERE id = 7 es una ventaja de aprendizaje.

PostgreSQL permite guardar documentos JSON en una columna. JSON guarda el texto tal cual; JSONB lo guarda en formato binario indexado, y es el que se usa en la práctica. Sirve para datos semiestructurados cuyo esquema varía (atributos específicos de cada producto, respuestas de una pasarela de pago, configuraciones).

Lo mencionamos aquí para que sepas que existe; su uso completo se trata en la lección 10-06. Y una advertencia: JSONB no es una excusa para no diseñar bien tus tablas. Lo que es estructurado va en columnas.

NULL no es cero, ni cadena vacía, ni FALSE. Significa "aquí no hay valor" o "no se sabe".

En TiendaVerde hay tres nulos con significado de negocio bien definido:

Lo esencial ahora es entender que NULL se propaga por cualquier operación:

Cualquier cálculo que toque un NULL devuelve NULL, porque operar con algo desconocido produce algo desconocido. Y como ya viste en la lección anterior, para comprobar si algo es nulo se usa IS NULL, nunca = NULL.

Distingue estos tres casos, que no son lo mismo:

El tratamiento completo de los nulos —cómo afectan a las agregaciones, a los JOIN y a los filtros— es la lección 04-03. Por ahora basta el concepto.

Si tienes que portar un esquema o leer código ajeno, esta tabla te ahorrará tiempo:

La diferencia más peligrosa está en la última fila. SQLite usa afinidad de tipos: si declaras una columna INTEGER y le insertas el texto 'hola', lo guarda sin protestar. Es cómodo para prototipar y desastroso para garantizar integridad. Es la razón principal por la que este curso usa PostgreSQL.

Cuando llegas a un proyecto nuevo, lo primero es entender su esquema. Hay dos caminos.

Un solo comando te da columnas, tipos, nulabilidad, valores por defecto, índices, claves foráneas y qué otras tablas apuntan a esta. Usa \d+ productos para ver además el tamaño y los comentarios.

El estándar SQL define un esquema de metadatos llamado information_schema, disponible en PostgreSQL, MySQL y SQL Server. Su ventaja sobre \d es que es SQL normal: puedes filtrarlo, ordenarlo y usarlo desde cualquier lenguaje.

Vistas útiles de information_schema:

Y una consulta que usarás a menudo para hacerte un mapa rápido de una base desconocida:

information_schema es el estándar, pero PostgreSQL tiene además su catálogo propio pg_catalog (pg_tables, pg_class, pg_attribute), más completo y más rápido, aunque no portable. Los metacomandos \d consultan precisamente ese catálogo.

• Guardar dinero en FLOAT o REAL. El error más caro de esta lección. Siempre NUMERIC(10,2).
• Guardar fechas como texto. VARCHAR para una fecha impide ordenar bien, calcular diferencias y validar. Usa DATE o TIMESTAMPTZ.
• Guardar números que no son cantidades como números. Un código postal (03001), un teléfono o un NIF son texto: si los guardas como INTEGER perderás el cero inicial y el +34.
• Poner VARCHAR(255) por costumbre. El 255 viene de MySQL antiguo. En PostgreSQL usa TEXT salvo que exista un límite de negocio real.
• Usar CHAR(n). El relleno con espacios provoca errores sutiles. Prácticamente nunca es la elección correcta.
• Confundir NULL con 0 o ''. Son tres cosas distintas y se comportan de forma distinta en filtros y agregaciones.
• Confiar en el orden de las filas. Sin ORDER BY no hay orden garantizado, por mucho que hoy salgan ordenadas.
• Consejo: elige el tipo pensando en cinco años vista. Cambiar el tipo de una columna con millones de filas en producción es una operación delicada (módulo 5).
• Consejo: \d tabla es tu primer comando en cualquier base ajena. Antes de escribir una consulta, mira la estructura.
• Consejo: pon nombres de tabla en plural y de columna en singular. productos.nombre se lee mejor que producto.nombres.

Para cada dato de TiendaVerde, elige el tipo PostgreSQL más adecuado y justifícalo en una línea:

1. El precio de venta de un producto.
2. El código de país de un proveedor en formato ISO (ES, PT, FR).
3. El comentario de una reseña.
4. La puntuación de una reseña (1 a 5).
5. La fecha en que se registró un cliente.
6. Si un producto está activo o no.
7. El instante exacto en que se confirmó un pago, con clientes en tres países.
8. El descuento aplicado a una línea de pedido (fracción de 0 a 1, dos decimales).

Ejecuta estas expresiones y explica qué demuestra cada una:

Escribe una consulta sobre information_schema que muestre todas las columnas de tipo numeric de la base de datos tiendaverde, indicando en qué tabla están y con qué precisión y escala. Ordénalas por tabla y por posición dentro de la tabla.

Solución 1

Solución 2

Solución 3

Resultado esperado sobre TiendaVerde:

Observa que data_type devuelve 'numeric' en minúsculas, y que la precisión y la escala vienen en columnas separadas: information_schema normaliza los tipos al vocabulario del estándar SQL, no al nombre que escribiste al crear la tabla.

En esta lección has recorrido la estructura sobre la que actúa SQL:

• La jerarquía servidor → base de datos → esquema (public) → tabla → columnas y filas, y por qué no se pueden consultar dos bases de datos a la vez en PostgreSQL.
• Una tabla es un conjunto de filas con la misma estructura, sin orden intrínseco, con un tipo por columna verificado por el motor: ahí está la gran diferencia con una hoja de cálculo.
• El catálogo de tipos de PostgreSQL: numéricos (INTEGER, BIGINT, NUMERIC(p,s), REAL), texto (TEXT, VARCHAR(n), CHAR(n)), fecha y hora (DATE, TIMESTAMP, TIMESTAMPTZ, INTERVAL), BOOLEAN, UUID y JSONB.
• La regla innegociable: el dinero va en NUMERIC, nunca en coma flotante, porque 0.1 + 0.2 <> 0.3 en binario.
• NULL como ausencia de valor, distinta de 0 y de '', que se propaga en toda operación.
• Las equivalencias de tipos entre PostgreSQL, MySQL y SQLite, y el peligro del sistema de tipos dinámico de SQLite.
• Cómo inspeccionar una base ajena con \dt, \d tabla e information_schema.columns.

En la siguiente lección, El modelo relacional: claves primarias y foráneas, veremos cómo las tablas dejan de estar aisladas y se relacionan entre sí: qué es una clave primaria y por qué usamos id subrogados, cómo las claves foráneas garantizan que no existan pedidos de clientes inexistentes, qué pasa al borrar un registro del que dependen otros, cómo se representan las cardinalidades 1:1, 1:N y N:M —con lineas_pedido como ejemplo real de tabla puente— y cómo la normalización explica por qué el esquema de TiendaVerde está partido en nueve tablas y no en una sola.