Terminamos la lección anterior con un esquema completo y una confesión: los tipos eran provisionales y las diez reglas de negocio del documento de requisitos no estaban en ninguna parte. Hoy, en el esquema tal como quedó, es perfectamente posible insertar una multa de −40 €, un evento que termina antes de empezar, una sala con aforo cero, una inscripción con estado 'confimada' y un socio con cuarenta teléfonos. El esquema es estructuralmente correcto y semánticamente indefenso.

Esta lección lo blinda. Tiene dos bloques y ambos son igual de importantes.

El primero es la elección razonada de tipos de datos. No es la lista de tipos de PostgreSQL —eso está en el manual—, sino las decisiones que hay detrás: cuándo un entero se queda corto, por qué el dinero de las multas de BiblioRed nunca puede ir en coma flotante (con una demostración ejecutable cuyo resultado sorprende), qué diferencia hay entre TIMESTAMP y TIMESTAMPTZ y por qué esa diferencia arruina agendas de eventos, si limitar la longitud de un texto sirve de algo, y por qué la colación decide si "Àngels" aparece antes o después de "Angel" cuando un socio busca en el catálogo.

El segundo es el catálogo de restricciones: NOT NULL, DEFAULT, UNIQUE con su comportamiento sorprendente ante los NULL, CHECK de una y de varias columnas, columnas generadas, dominios reutilizables, cómo nombrarlas para que los errores de producción sean legibles y cómo añadirlas a una tabla que ya tiene datos sin bloquear el servicio.

El entregable es la versión definitiva y blindada del esquema de BiblioRed ampliado, y con ella se cierra el módulo 4.

1. Por qué el tipo de dato es una decisión de diseño
2. Enteros: SMALLINT, INTEGER, BIGINT y el día que se acaban
3. NUMERIC frente a REAL: por qué el dinero nunca va en coma flotante
4. Texto: CHAR, VARCHAR(n) y TEXT
5. Fechas y horas: TIMESTAMP frente a TIMESTAMPTZ, e INTERVAL
6. BOOLEAN y las trampas de 'S'/'N'
7. UUID frente a entero secuencial como clave
8. Conjuntos cerrados de valores: ENUM, tabla de catálogo o CHECK
9. JSONB y arrays como escapes controlados
10. BYTEA y por qué las portadas no van en la base
11. Codificación y colación: buscar títulos en español y catalán
12. Los tipos permisivos de SQLite frente a los estrictos de PostgreSQL
13. NOT NULL: la decisión de permitir ausencias
14. DEFAULT: valores por omisión
15. UNIQUE simple y compuesto, y su relación con NULL
16. PRIMARY KEY como combinación de las anteriores
17. CHECK: codificar reglas de negocio en el esquema
18. Columnas generadas y dominios
19. Nombrar las restricciones y leer los errores de producción
20. Añadir restricciones a una tabla que ya tiene datos
21. Qué reglas van en la base de datos y cuáles en la aplicación
22. Entregable: el esquema definitivo de BiblioRed ampliado
23. Errores Comunes y Consejos
24. Ejercicios
25. Conclusión

Elegir un tipo parece trámite. En realidad se están decidiendo cuatro cosas a la vez:

Un tipo mal elegido no da error: da resultados incorrectos en silencio, que es peor. Una fecha guardada como VARCHAR funciona perfectamente hasta el día en que alguien ordena la agenda de eventos y aparece diciembre antes que febrero.

La pregunta correcta no es "¿cuántas filas habrá?", sino "¿cuántas veces se incrementará el contador?", y son cosas distintas: las filas borradas consumen valores que no se reutilizan.

Los volúmenes de BiblioRed a tres años (apartado D del documento de requisitos) son 55.000 ejemplares, 30.000 inscripciones y 9.000 multas. INTEGER da margen para 2.147 millones. Aunque BiblioRed multiplicara su tamaño por mil, no se acercaría. INTEGER es correcto para todas las claves de este esquema.

El caso en que no lo es tiene una señal clara: tablas donde se insertan filas por eventos automáticos, no por acciones humanas. Un registro de accesos a la web con 500 inserciones por segundo agota un INTEGER en unos cincuenta días. La regla práctica:

Si las filas las genera una persona, INTEGER sobra. Si las genera una máquina, calcula.

Y una advertencia real: cambiar de INTEGER a BIGINT en una tabla grande y muy referenciada es una de las migraciones más dolorosas que existen, porque reescribe la tabla, todos sus índices y todas las columnas de las claves ajenas que la referencian. Si hay una duda razonable, BIGINT desde el principio cuesta 4 bytes por fila.

No es por ahorrar bytes: es por documentar la intención. Un aforo SMALLINT dice a quien lee el esquema que ninguna sala municipal albergará 40.000 personas. Es una restricción débil pero gratuita, y complementa al CHECK que le pondremos después.

Este es el apartado más importante de la lección y el que más veces se ignora en proyectos reales.

Los tipos de coma flotante representan los números en binario. Y hay decimales sencillos que en binario son periódicos infinitos, igual que 1/3 lo es en decimal. 0,1 es uno de ellos. Lo que se guarda no es 0,1: es lo más cercano a 0,1 que cabe en 64 bits.

Tres multas de BiblioRed: 3,10 €, 2,20 € y 4,30 €. El total debería ser exactamente 9,60 €.

No es un error de PostgreSQL: es cómo funciona el binario, y ocurre igual en Java, Python, JavaScript y C. Ahora las consecuencias prácticas:

Una multa pagada íntegramente aparecería como impagada. La comprobación de RN5 ("la suma de los pagos nunca supera el importe") y la consulta C7 ("socios con deuda superior a 20 €") darían resultados aleatorios.

El error se agrava al acumular. Los recargos de BiblioRed son de 0,20 €/día:

Tres céntimas de diferencia en mil operaciones. En un cierre contable municipal, eso es una incidencia que alguien tiene que investigar. (El valor exacto puede variar ligeramente según la plataforma; lo invariable es que no sea exacto.)

Todo lo que se cuenta en dinero, todo lo que se factura y todo lo que se compara por igualdad va en NUMERIC(p,s). La coma flotante es para magnitudes físicas donde un error de 10⁻¹⁵ es irrelevante.

En BiblioRed:

Sobre NUMERIC(6,2): 6 es el total de dígitos (precisión) y 2 los decimales (escala), así que la parte entera admite cuatro dígitos. El gestor redondea al insertar y rechaza lo que desborda:

El desbordamiento avisa; el redondeo no. Si BiblioRed llegara a emitir multas por pérdida de material de más de 10.000 €, habría que ampliar a NUMERIC(8,2).

Nota sobre MONEY: PostgreSQL tiene un tipo MONEY, pero depende de la configuración regional del servidor y no lleva la moneda dentro. Se desaconseja: NUMERIC es la opción portable.

El valor lleva tres espacios de relleno que aparecen al concatenar, al exportar a CSV y al comparar desde una aplicación que no aplica las reglas de SQL. Es una fuente de errores desproporcionada al beneficio, que en PostgreSQL es ninguno: CHAR(n) no es más rápido ni ocupa menos.

En PostgreSQL, VARCHAR(n) y TEXT se almacenan exactamente igual. VARCHAR(200) no reserva 200 bytes; el n es solo una restricción de validación. Así que la pregunta es si esa validación aporta.

Sí aporta cuando el límite es una regla de negocio real:

No aporta cuando el número es inventado. titulo VARCHAR(200) no responde a ninguna regla: es un número que alguien puso porque había que poner uno. Y tiene un coste real, porque el día que llegue un título de 214 caracteres —los hay— la inserción fallará en producción, con un error que el equipo tendrá que diagnosticar de madrugada:

Criterio de BiblioRed: VARCHAR(n) solo donde n sale de una norma externa. TEXT para títulos, descripciones, observaciones, biografías y nombres. Donde el negocio quiera un tope orientativo pero no crítico, se pone con un CHECK nombrado, que se puede relajar sin reescribir la tabla:

Ventaja no obvia: ampliar VARCHAR(200) a VARCHAR(300) es un ALTER TABLE que en versiones antiguas reescribía la tabla; relajar un CHECK es soltar y volver a crear una restricción.

TIMESTAMPTZ no almacena la zona horaria. Almacena el instante absoluto (UTC) y lo convierte a la zona de la sesión al leerlo. TIMESTAMP guarda una pared de reloj sin contexto.

Ahora un socio consulta la agenda desde el extranjero, o un proceso automático se ejecuta con otra configuración:

con_tz dice correctamente que el club de lectura de las 18:00 en Vallmar son las 11:00 en Bogotá: es el mismo instante. sin_tz dice 18:00 en las dos, lo cual es falso en una de ellas y no hay forma de saber en cuál.

Y hay un caso donde el daño ocurre sin salir de Vallmar: el cambio de hora. La madrugada del último domingo de octubre, las 02:30 existe dos veces. Un TIMESTAMP sin zona no puede distinguirlas; un TIMESTAMPTZ sí, porque internamente son dos instantes UTC distintos.

Regla: todo instante de un hecho —cuándo empieza un evento, cuándo se hizo una inscripción, cuándo se registró un pago— va en TIMESTAMPTZ. Úsalo por defecto y justifica cuando no lo hagas.

TIMESTAMP sin zona tiene un uso legítimo y estrecho: horarios recurrentes que son "hora local" por definición, como "la biblioteca abre a las 9:00" independientemente de la estación. Ahí lo correcto suele ser TIME, no TIMESTAMP.

No todo necesita hora. fecha_prestamo, fecha_devolucion_prevista, fecha_emision de una multa y fecha_alta de un material son fechas: la biblioteca no cobra por horas. Usar TIMESTAMPTZ ahí obliga a arrastrar un 00:00:00 que confunde y complica las comparaciones de rango.

INTERVAL representa una duración y se suma directamente a fechas:

Detalle a notar: DATE − DATE da un entero de días, no un intervalo, que es justo lo que hace falta para calcular el recargo de R10 a 0,20 €/día. En cambio TIMESTAMPTZ − TIMESTAMPTZ sí devuelve un INTERVAL, y lo usaremos en el apartado 18 para la duración de los eventos.

PostgreSQL tiene BOOLEAN con tres valores posibles: TRUE, FALSE y NULL (lógica trivalente de 02-01).

Comparémoslo con la costumbre heredada de sistemas antiguos de usar CHAR(1) con 'S'/'N':

En BiblioRed son BOOLEAN: socios.activo, salas.accesible, eventos.publicado, ponentes.externo.

Una precisión que evita un error frecuente: un booleano NULL significa "no se sabe", y eso a veces es legítimo (accesible de una sala que aún no se ha inspeccionado) y a veces es un descuido. Si el tercer valor no tiene sentido en el dominio, declara NOT NULL DEFAULT y elimina la duda. Todos los booleanos de BiblioRed son NOT NULL.

Cuándo compensa UUID: identificadores que viajan en URLs públicas, sistemas distribuidos que generan filas sin conexión, fusión de bases de datos independientes.

El caso de BiblioRed: claves internas de una base centralizada con volúmenes moderados. Entero secuencial, sin discusión. Los socio_id y evento_id no aparecen en URLs públicas; si mañana la web expusiera /eventos/47, la solución no es cambiar la clave primaria sino añadir un identificador público aparte:

Así la clave primaria sigue siendo compacta para las claves ajenas y los índices, y la exposición pública no filtra el volumen del negocio. Es la mejor de las dos opciones y casi nadie la considera.

BiblioRed tiene ocho columnas con un conjunto cerrado: materiales.tipo_material, ejemplares.estado, reservas.estado, eventos.estado, inscripciones.estado, multas.motivo, multas.estado, pagos.metodo, telefonos_socio.tipo, participaciones.rol y eventos_materiales.papel. Hay tres formas de implementarlo.

Compacto (4 bytes), ordenación natural según el orden de declaración, error clarísimo. Sus dos inconvenientes son reales: no se pueden eliminar valores (solo añadir, y desde PostgreSQL 12 con ADD VALUE), y no admite atributos: no se puede guardar la descripción de cada estado ni su orden de presentación.

Los valores se gestionan con INSERT/UPDATE sin tocar el esquema, admiten atributos y se pueden traducir. El precio es un JOIN cada vez que se quiere el nombre legible, y una tabla más.

Sin tipos nuevos, sin tablas nuevas, y modificar la lista es soltar y recrear la restricción.

Si el conjunto lo gestiona el usuario, tabla de catálogo. Si lo gestiona el desarrollador y cambia poco, CHECK. ENUM solo cuando el conjunto sea inmutable de verdad.

Ninguna columna usa ENUM. La razón es la portabilidad —el esquema debe poder cargarse en SQLite para pruebas— y la rigidez de eliminar valores. Es una decisión defendible, no la única posible.

En 03-03 modelamos documentos en MongoDB y en 03-04 vimos que PostgreSQL guarda documentos con jsonb. Aquí toca la pregunta de diseño: ¿cuándo es legítimo usarlos en un esquema relacional?

Un array no es una lista con comas: conserva la estructura, tiene operadores propios (@> contiene, && se solapa) y se puede indexar con GIN (06-03). Pero comparado con la tabla subtitulos_dvd de 04-03 pierde tres cosas: no puede tener clave ajena a un catálogo de idiomas, no admite atributos por elemento (¿son subtítulos para sordos?) y las agregaciones ("¿cuántos DVD por idioma?") requieren unnest.

Decisión de BiblioRed: la tabla. El array es la opción correcta cuando los elementos son etiquetas sin estructura y solo se consultan por pertenencia.

El uso legítimo es datos genuinamente variables cuya estructura no se conoce en tiempo de diseño. En BiblioRed hay un caso: las respuestas a las encuestas de satisfacción de los eventos (R9). Cada tipo de evento tiene su cuestionario, el número y tipo de preguntas cambia, y se añaden preguntas sin avisar.

La línea que no hay que cruzar: JSONB no es un sitio donde meter columnas para no diseñarlas. Si un dato se consulta siempre, se filtra, se agrega o tiene una regla de negocio asociada, es una columna. Meter asistentes_reales dentro del JSON sería el anti-patrón EAV de 04-01 con sintaxis moderna.

Criterio: columna si el dato tiene nombre conocido, tipo conocido y reglas; JSONB si la forma la decide alguien ajeno al esquema. Y si acabas escribiendo un CHECK complejo sobre una clave del JSON, esa clave quería ser una columna.

BYTEA guarda datos binarios. La tentación es guardar dentro de la base las portadas de los libros y los PDF de los informes. No lo hagas, salvo con muy buenas razones:

Lo correcto: guardar el fichero en el sistema de archivos o en almacenamiento de objetos, y en la base la ruta y los metadatos:

Las excepciones legítimas son pocas y reconocibles: binarios pequeños (menos de unos pocos KB), poco numerosos, que deban participar de la transacción y del control de acceso de la base —una firma digital, un sello de tiempo—.

BiblioRed maneja títulos en castellano y catalán. Esto convierte dos parámetros normalmente invisibles en decisiones de diseño.

UTF-8 representa cualquier carácter de cualquier idioma: ñ, ç, à, ï, · (el punto volado catalán de "col·lecció"), comillas tipográficas y emojis. Cualquier codificación de un solo byte (LATIN1) romperá algo tarde o temprano, y la migración posterior es laboriosa. No hay decisión que tomar aquí: UTF-8.

La colación son las reglas de ordenación y comparación de cadenas. No es un detalle cosmético: decide el resultado de ORDER BY, de < y >, y de los índices que se apoyen en ese orden.

La colación "C" ordena por el valor byte a byte: todas las mayúsculas antes que todas las minúsculas, y los acentuados al final. Es rápida y completamente inaceptable para un catálogo bibliotecario.

Este es el orden que espera cualquier persona: los acentos y las mayúsculas no alteran la posición alfabética.

Un socio que busca "mapa del tiempo" debe encontrar "El Mapa del Tiempo", y quien busca "angels" debe encontrar "Àngels". Dos piezas:

Desde PostgreSQL 12 existe además la opción más limpia: una colación no determinista que ignora acentos y mayúsculas para la comparación, aplicable a una columna concreta.

Decisión de BiblioRed: colación por defecto es-ES-x-icu en la base (ordenación correcta) y búsqueda con unaccent + ILIKE en las consultas del catálogo. Las columnas de códigos (isbn, codigo de ejemplar, idioma) llevan colación "C" explícita: son códigos, no texto, y comparar byte a byte es lo correcto y lo más rápido.

Advertencia operativa: cambiar la colación de una base con datos invalida los índices construidos sobre columnas de texto, porque su orden deja de ser válido. Hay que reconstruirlos (REINDEX). Es una decisión que se toma al crear la base y no se cambia a la ligera.

En 01-04 instalamos SQLite como alternativa ligera. Su sistema de tipos funciona de una manera que sorprende a quien viene de PostgreSQL, y hay que conocerla porque es una fuente clásica de datos corruptos.

SQLite usa afinidad de tipos: el tipo declarado es una preferencia, no una restricción.

Ningún error. La misma sentencia en PostgreSQL:

Las diferencias que más afectan al diseño:

Desde SQLite 3.37 (2021) existe una solución parcial:

Recomendación para BiblioRed: PostgreSQL es la referencia. Si se usa SQLite para pruebas locales, hay que declarar las tablas STRICT, activar PRAGMA foreign_keys = ON y no guardar dinero en REAL —los importes se almacenan como enteros de céntimos—. Sabiendo eso, SQLite es una herramienta excelente; sin saberlo, es una trampa.

Empieza el segundo bloque. NOT NULL es la restricción más simple y la que más se decide por inercia.

En 02-01 vimos que NULL no es cero ni cadena vacía: es "no se sabe" o "no aplica". Permitirlo en una columna es afirmar que ese caso existe en el negocio. La pregunta correcta es: "¿existe una fila legítima en la que esto no se sepa?"

La fila de acompanantes es la más instructiva. Es la distinción entre cero y desconocido, y confundirla es el error más común con NULL. Un socio que va solo tiene 0 acompañantes, no un número desconocido de acompañantes. La combinación NOT NULL DEFAULT 0 lo expresa exactamente y además hace que SUM(1 + acompanantes) funcione sin COALESCE.

Consejo práctico: empieza declarando todo NOT NULL y quita la restricción solo donde puedas nombrar la fila legítima que la incumple. El sentido por defecto opuesto —permitir nulos y restringir después— produce esquemas donde nadie sabe qué columnas pueden faltar.

Un DEFAULT se aplica cuando la columna se omite en el INSERT, no cuando se le pasa NULL explícitamente:

El DEFAULT no rescata un NULL explícito. Es un comportamiento correcto y sorprende a mucha gente.

• CURRENT_DATE → fecha del día.
• now() / CURRENT_TIMESTAMP → instante de inicio de la transacción, no de la sentencia. Todas las filas insertadas en la misma transacción llevan la misma marca, lo cual suele ser lo deseable.
• clock_timestamp() → instante real de cada llamada. Se usa para medir, casi nunca como DEFAULT.

Poner el valor por defecto en la base garantiza que cualquier vía de inserción lo respete: la aplicación web, un script de importación, una carga masiva o un INSERT manual desde psql. Si el valor por defecto solo vive en el código de la aplicación, la primera carga masiva lo saltará. Es el mismo argumento que cierra el apartado 21.

UNIQUE garantiza que no haya dos filas con el mismo valor. En BiblioRed, cada clave natural del apartado 10 de 04-01 lleva la suya:

El compuesto aplica a la combinación, no a cada columna:

Dos salas con el mismo nombre en sucursales distintas: correcto según R3.

En SQL estándar, NULL no es igual a NULL (lógica trivalente, 02-01). Como UNIQUE prohíbe valores iguales y dos NULL no lo son, una columna UNIQUE admite tantos NULL como quieras:

Tres ponentes sin correo, con UNIQUE (email). No es un fallo: es lo que permite combinar "el correo es opcional" con "dos ponentes no comparten correo", que era justo lo que necesitábamos en 04-03.

Recuerda la restricción uq_multas_prestamo_motivo UNIQUE (prestamo_id, motivo), que implementaba R10 ("un préstamo genera como mucho una multa de cada motivo"). Como prestamo_id es anulable por la decisión D6, tiene un agujero:

Tres multas idénticas por la misma pérdida, y el UNIQUE no ha dicho nada porque cada (NULL, 'perdida') es distinto de los demás. Es un duplicado real en producción.

Desde PostgreSQL 15 hay una solución declarativa:

Con NULLS NOT DISTINCT, los NULL se consideran iguales entre sí a efectos de unicidad. En versiones anteriores a la 15 se resolvía con un índice único parcial, que es materia de 06-03.

La lección de fondo: un UNIQUE sobre columnas anulables no garantiza lo que parece garantizar. Cada vez que declares uno, comprueba si alguna de sus columnas admite NULL y decide conscientemente.

PRIMARY KEY no es una restricción nueva: equivale a UNIQUE + NOT NULL, más el papel de identificador por defecto de las claves ajenas.

Las tres diferencias que sí importan:

1. Solo puede haber una clave primaria por tabla; claves UNIQUE, las que hagan falta.
2. REFERENCES tabla sin columna apunta implícitamente a la clave primaria.
3. Herramientas, ORM y clientes gráficos la usan para identificar la fila.

En BiblioRed conviven los dos usos: materiales tiene PRIMARY KEY (material_id) y además UNIQUE (material_id, tipo_material), esta última existiendo únicamente para que las subtablas puedan referenciarla con la clave ajena compuesta de la regla 10.

Aquí es donde las diez reglas de negocio de 04-01 entran por fin en el esquema.

Comprobación:

Un CHECK declarado a nivel de tabla puede referirse a varias columnas de la misma fila:

Fíjate en la construcción de chk_prestamos_devolucion: incluye el caso NULL explícitamente. Es imprescindible saber cómo trata CHECK a los nulos.

Un CHECK acepta la fila cuando la expresión da TRUE o NULL. Solo la rechaza cuando da FALSE.

Se acepta porque fecha_devolucion es NULL y NULL >= '2026-07-01' da NULL, no FALSE. En este caso concreto es lo que queríamos —un préstamo no devuelto es válido—, pero el comportamiento es fácil de confundir. Si quieres rechazar los nulos, hazlo explícito con NOT NULL o con IS NOT NULL dentro del CHECK.

Un CHECK solo ve la fila que se está insertando o modificando. No puede consultar otras tablas ni otras filas. Esto deja fuera cuatro de las diez reglas de negocio:

Para RN4, PostgreSQL ofrece una herramienta específica y poco conocida, la restricción de exclusión, que generaliza UNIQUE a cualquier operador:

Se lee: no pueden existir dos filas no canceladas con la misma sala_id cuyos rangos de tiempo se solapen.

RN4 garantizada por el servidor, con concurrencia correcta y sin una línea de código de aplicación. Es de lo mejor que ofrece PostgreSQL y no tiene equivalente en SQLite.

Una columna generada se calcula a partir de otras de la misma fila. Es la manera correcta de materializar un derivado sencillo sin riesgo de desincronización, porque el gestor la mantiene y nadie puede escribirla.

No se puede mentir. Esa es la diferencia esencial con la desnormalización manual de 05-04: aquí el gestor garantiza la coherencia.

Dos límites: en PostgreSQL solo existe STORED (se almacena; no hay columnas virtuales calculadas al vuelo), y la expresión debe ser inmutable y referirse solo a columnas de la misma fila. Por eso plazas_libres de un evento —que agrega otra tabla— no puede ser una columna generada y sigue siendo la vista v_eventos_ocupacion de 04-03.

Un dominio es un tipo propio construido sobre otro, con restricciones incorporadas. Sirve para no repetir la misma validación en quince sitios y para que el esquema exprese el vocabulario del negocio.

Y se usan como si fueran tipos:

Su inconveniente es la portabilidad: los dominios son de SQL estándar pero SQLite no los tiene, así que un esquema con dominios necesita una versión alternativa para las pruebas locales.

Si no nombras una restricción, PostgreSQL le pone un nombre automático. Compara los dos mensajes.

Sin nombre:

Con nombre:

Parece un detalle estético. No lo es, por tres razones concretas:

1. El equipo de soporte lee el mensaje. chk_salas_aforo_positivo se entiende sin abrir el esquema; salas_aforo_check obliga a investigar. Con dos CHECK en la misma columna, el nombre autogenerado es salas_aforo_check1, y ahí ya no hay nada que hacer.
2. La aplicación puede reaccionar al nombre. El código captura el error, lee el nombre de la restricción y muestra el mensaje adecuado al usuario. Con nombres autogenerados, esa lógica se rompe en cuanto alguien recrea una tabla y los sufijos cambian de orden.
3. Las migraciones necesitan el nombre. ALTER TABLE ... DROP CONSTRAINT exige saberlo, y consultar el catálogo cada vez es fricción innecesaria.

Convención de BiblioRed:

Y la forma del nombre: <prefijo>_<tabla>_<qué comprueba>. Los nombres son globales por esquema, así que incluir la tabla evita colisiones.

El caso real: prestamos tiene 4.312 filas y ninguna restricción sobre el recargo. Si intentas añadirla directamente:

Ocurren dos cosas. Si hay datos que la incumplen:

Y si no los hay, PostgreSQL recorre la tabla entera para verificarlo, manteniendo un bloqueo que impide leer y escribir. Con 4.312 filas es instantáneo; con diez millones, es una parada de servicio.

Paso 1 — Averiguar cuántas filas incumplen:

Paso 2 — Corregir los datos existentes:

Paso 3 — Añadir la restricción con NOT VALID y validarla después:

NOT VALID significa: "la restricción se aplica desde ahora a toda fila nueva o modificada, pero no compruebes las que ya están". Es instantáneo y toma un bloqueo mucho más ligero. La base queda protegida de inmediato contra datos nuevos incorrectos.

Después, en una ventana tranquila:

VALIDATE CONSTRAINT recorre la tabla, pero con un bloqueo que permite lecturas y escrituras concurrentes. Si encuentra una fila que incumple, falla y la restricción se queda en NOT VALID; no se pierde nada.

Se puede consultar el estado en el catálogo:

NOT VALID funciona igual con claves ajenas y es la técnica estándar para añadir integridad referencial a una base grande sin parar el servicio. NOT NULL es la excepción: no admite NOT VALID hasta PostgreSQL 18; el rodeo clásico es añadir primero un CHECK (col IS NOT NULL) NOT VALID, validarlo y convertirlo después.

En 02-06 defendimos la integridad referencial en el servidor. Ahora toca el criterio general, porque no todo cabe en el esquema.

La base de datos es el único punto por el que pasan todos los caminos. La aplicación web, la aplicación móvil, el script nocturno de importación del catálogo, la carga masiva del proveedor, el becario con psql y el proceso de migración: todos escriben en la misma base. Una regla que vive solo en la aplicación web la incumplen los otros cinco.

Además, las aplicaciones se reescriben; los datos permanecen. Y una regla en la base se aplica retroactivamente en el sentido de que impide que el problema vuelva a aparecer, mientras que corregir el código no arregla los datos ya corrompidos.

La última fila incomoda a mucha gente: ¿no es duplicar trabajo? No, porque cumplen funciones distintas:

• La aplicación valida para dar una buena experiencia: un mensaje claro junto al campo, antes de enviar el formulario, en el idioma del usuario.
• La base valida para dar una garantía: nada entra mal, venga por donde venga.

La primera se puede saltar; la segunda no. Duplicar la validación de formato en los dos sitios es correcto y esperado. Lo que no es correcto es tenerla solo en la aplicación.

La regla que resume el apartado: si el dato incorrecto causaría un problema aunque nadie lo mirara nunca por pantalla, la regla va en la base.

Aquí está el resultado del módulo 4 completo. Es la migración V005, que revisa los tipos provisionales de 04-03 y añade el blindaje.

Cinco de diez en el esquema, con garantía absoluta. Las otras cinco requieren consultar otras tablas o agregar filas, y quedan documentadas con su ubicación decidida. Eso también es diseño: saber exactamente dónde vive cada regla y por qué.

Guardar dinero en REAL o DOUBLE PRECISION. El error más caro de esta lección y el más frecuente en proyectos reales. Los importes no cuadran, las sumas fallan por céntimos y nadie encuentra el motivo durante semanas. NUMERIC, siempre.

Usar TIMESTAMP sin zona horaria "porque solo operamos en España". Basta un servidor en otra zona, un contenedor con UTC por defecto o un cambio de hora para que la agenda de eventos deje de ser fiable. TIMESTAMPTZ por defecto.

Guardar fechas como texto. '14/05/2026' ordena mal, no permite restar, no valida y depende del formato regional. Una fecha es un DATE.

Poner VARCHAR(n) con un n inventado. El error aparece en producción con el primer valor largo, y en el peor momento. TEXT más un CHECK de longitud si hace falta.

Declarar UNIQUE sobre columnas anulables sin pensarlo. Los NULL no se consideran iguales: la unicidad que creías tener no existe. Es el agujero de uq_multas_prestamo_motivo, y se cierra con NULLS NOT DISTINCT.

Confundir cero con desconocido. acompanantes = 0 significa que va solo; acompanantes IS NULL significa que no lo sabemos. Si el negocio no admite el segundo caso, declara NOT NULL DEFAULT 0.

Olvidar que CHECK acepta NULL. CHECK (importe > 0) no impide importe IS NULL. Si el valor es obligatorio, hace falta también NOT NULL.

No nombrar las restricciones. El día que el error salga en producción a las tres de la madrugada, alguien tendrá que averiguar qué significa eventos_check2.

Añadir una restricción a una tabla grande sin NOT VALID. Bloquea la tabla durante la verificación completa. Con NOT VALID la protección es inmediata y la verificación se hace después sin cortar el servicio.

Meter en JSONB lo que quería ser una columna. Si el dato se filtra, se agrega o tiene reglas, es una columna. JSONB es para estructuras genuinamente variables.

Consejo: escribe primero la restricción y luego intenta violarla. Un CHECK que nunca has visto fallar puede estar mal escrito. Los mensajes de error de este capítulo salieron todos de ejecutar el INSERT que debía fallar.

Consejo: repasa el esquema columna por columna preguntando "¿qué valor absurdo cabe aquí?". Aforo cero, importe negativo, evento de duración negativa, estado con errata, código postal de tres cifras. Cada respuesta es una restricción que falta.

Consejo: los dominios se pagan solos a partir de la tercera columna igual. Tres correos, cuatro importes, cinco códigos de idioma: si repites el mismo CHECK, ya es un dominio.

Para cada columna, elige el tipo definitivo y justifícalo en una o dos frases. Indica también si debe llevar NOT NULL y con qué DEFAULT.

1. salas.metros_cuadrados — superficie de la sala, con un decimal.
2. eventos.aforo_reducido_covid — porcentaje entero de aforo permitido (0-100).
3. pagos.referencia_pasarela — identificador que devuelve la pasarela del ayuntamiento, cadena alfanumérica de 32 caracteres.
4. socios.fecha_nacimiento — para estadísticas por franja de edad.
5. materiales.veces_prestado — número total de préstamos históricos del material.
6. inscripciones.recordatorio_enviado_en — cuándo se envió el recordatorio, si se envió.

Para cada regla, decide si se puede expresar con una restricción declarativa. Si es que sí, escribe el ALTER TABLE ... ADD CONSTRAINT con nombre; si es que no, explica por qué y dónde debería vivir.

1. La valoración media de un informe está entre 0 y 5.
2. Un evento cancelado no puede estar publicado.
3. Un ejemplar en estado 'baja' no puede prestarse.
4. El código de un ejemplar empieza siempre por EJ-.
5. Una sala no puede tener dos eventos solapados.
6. Un socio no puede tener más de tres teléfonos.
7. Los honorarios de un ponente no externo son siempre 0.

Un equipo externo entrega esta tabla para gestionar las cuotas anuales de los socios. Localiza al menos siete problemas de tipo o de restricción, explica el daño concreto en BiblioRed y escribe la versión corregida.

Solución al Ejercicio 1

La 5 es la respuesta clave: la pregunta pedía un tipo y la respuesta correcta es que no debe existir la columna.

Solución al Ejercicio 2

Verificación:

Comentario sobre la 7: la tentación es "pues copio externo a participaciones". Es redundancia y crea la posibilidad de que las dos copias discrepen. La respuesta correcta en la v1.0 es la aplicación, y anotarlo en el diccionario de datos.

Solución al Ejercicio 3

Versión corregida:

Las dos mejoras que van más allá de corregir tipos son chk_cuotas_coherencia_pago —que impide el estado incoherente "pagada sin fecha de pago", un CHECK de tres columnas— y la columna generada importe_final, que garantiza que el descuento aplicado nunca pueda desincronizarse del importe base.

Esta lección ha convertido un esquema estructuralmente correcto en un esquema que se defiende solo, y con ella se cierra el módulo 4.

Sobre los tipos:

• El tipo decide cuatro cosas a la vez: qué valores caben, qué operaciones tienen sentido, cómo se ordena y cuánto cuesta. Un tipo mal elegido no da error: da resultados incorrectos en silencio.
• Enteros: SMALLINT documenta la intención, INTEGER sobra para todo lo que genera una persona, BIGINT para lo que genera una máquina. Migrar de INTEGER a BIGINT en una tabla grande y referenciada es de las peores migraciones que existen.
• NUMERIC frente a coma flotante es el apartado que hay que recordar: 3.10 + 2.20 + 4.30 da 9.600000000000001 en DOUBLE PRECISION, y por eso una multa pagada íntegramente puede aparecer como impagada. Todo lo que es dinero va en NUMERIC.
• Texto: CHAR(n) casi nunca; VARCHAR(n) solo cuando n sale de una norma externa (ISBN, ISSN, código postal); TEXT para todo lo demás, con CHECK de longitud si el negocio quiere un tope.
• Fechas: TIMESTAMPTZ por defecto para los instantes de hechos, porque guarda el momento absoluto y sobrevive a las zonas horarias y al cambio de hora; DATE cuando la hora no existe en el dominio; INTERVAL para calcular vencimientos.
• BOOLEAN en lugar de 'S'/'N', y NOT NULL cuando el tercer valor no significa nada.
• UUID solo si los identificadores viajan por URLs públicas o hay generación distribuida; para BiblioRed, entero secuencial, y si hace falta exponer algo, un identificador público adicional.
• Conjuntos cerrados: tabla de catálogo si los gestiona el usuario, CHECK si los gestiona el desarrollador, ENUM solo si son inmutables de verdad.
• JSONB y arrays son escapes legítimos para estructuras genuinamente variables —las encuestas de los eventos—, no un sitio donde meter columnas sin diseñar.
• BYTEA: las portadas no van en la base; van en almacenamiento de objetos y en la base su ruta y su hash.
• Codificación y colación: UTF-8 sin discusión, y la colación decide si "Àngels" se ordena donde una persona espera. Los códigos llevan colación "C"; el texto de catálogo, es-ES-x-icu con unaccent para buscar.
• SQLite usa afinidad de tipos: acepta texto en una columna INTEGER. Con STRICT, PRAGMA foreign_keys = ON y los importes en céntimos enteros, es una herramienta excelente; sin eso, es una trampa.

Sobre las restricciones:

• NOT NULL por defecto, y quitarlo solo donde puedas nombrar la fila legítima que lo incumple. La distinción entre cero y desconocido es el error más común.
• DEFAULT vive en la base para que lo respeten todas las vías de escritura, no solo la aplicación web. No rescata un NULL explícito.
• UNIQUE sobre columnas anulables no garantiza lo que parece: varios NULL conviven, y eso abrió un agujero real en uq_multas_prestamo_motivo que se cerró con NULLS NOT DISTINCT.
• CHECK acepta la fila cuando la expresión da TRUE o NULL; solo la rechaza con FALSE. Y no puede mirar otras filas ni otras tablas, lo que deja fuera cinco de las diez reglas de negocio. Para el no solapamiento existe la restricción de exclusión, que garantiza RN4 en el servidor con concurrencia correcta.
• Columnas generadas materializan derivados de la misma fila con garantía del gestor: no se pueden escribir a mano, así que no pueden mentir.
• Dominios centralizan una validación repetida y hacen que el esquema hable el idioma del negocio.
• Nombrar las restricciones convierte un error de producción ilegible en un diagnóstico inmediato, permite que la aplicación reaccione al nombre y hace posibles las migraciones.
• NOT VALID + VALIDATE CONSTRAINT es la forma de añadir integridad a una tabla grande sin parar el servicio: protege de inmediato lo nuevo y verifica lo viejo después.
• El criterio de fondo: si el dato incorrecto causaría un problema aunque nadie lo mirara nunca por pantalla, la regla va en la base. La aplicación valida para dar buena experiencia; la base valida para dar garantía. Duplicarlo es correcto; tenerlo solo en la aplicación, no.

Con esto se cierra el módulo 4, Diseño de Esquemas, y la ampliación de BiblioRed está terminada de principio a fin: partimos de una frase del ayuntamiento, la convertimos en un documento de requisitos con catorce puntos, diez reglas de negocio y doce consultas; lo dibujamos como un modelo conceptual con veintiuna entidades y nueve decisiones razonadas; lo transformamos en tablas aplicando diez reglas mecánicas; y lo hemos blindado con tipos elegidos uno a uno y restricciones que hacen imposibles los estados inválidos. El esquema que tenemos ahora no es el que habríamos escrito el primer día abriendo el editor, y esa diferencia es exactamente lo que enseña este módulo. En el módulo 5, Normalización, sometemos ese esquema a un examen que hasta ahora hemos evitado deliberadamente: dejamos la intuición de "una cosa, un sitio" y pasamos al instrumental formal —dependencias funcionales, primera, segunda y tercera forma normal, Boyce-Codd— para comprobar con matemáticas si el diseño de BiblioRed aguanta, corregir lo que no aguante, y entender después por qué a veces conviene romper esas reglas a propósito.