Cuándo romper las reglas de la base de datos:3 casos

Saber cuándo romper las reglas de la base de datos significa tener una razón específica y documentada, y en la práctica solo tres razones superan el escrutinio. Los datos de verdad flexibles pueden vivir en JSONB en lugar de en tablas rígidas. Los contadores que serían demasiado caros de calcular en vivo pueden almacenarse. Y el dinero se guarda siempre en céntimos enteros. Todo lo demás se mantiene estrictamente estructurado.

He dedicado muchas palabras a predicar la estructura: cada dato en un solo lugar, todo conectado mediante referencias, sin atajos. Esa regla, la disciplina del 90 % o más que se explica en la normalización de bases de datos, construyó una plataforma en la que cientos de tablas se mantienen sincronizadas sin datos duplicados. Este artículo trata del otro lado: el 10 %, donde romper las reglas no es un atajo sino la decisión de ingeniería correcta.

Cuándo romper las reglas de la base de datos: la regla antes que las excepciones

Primero, el marco. En mi plataforma, probablemente el 95 % de los datos es relacional: tablas correctas, referencias correctas, estructura correcta. Las excepciones son exactamente eso, excepciones, cada una con una razón escrita. Ese orden importa, porque la IA te ofrecerá romper reglas constantemente y “es más sencillo” nunca es la razón. El peligro no es la excepción; es la excepción sin documentar que nadie podrá distinguir después de un error.

Dicho esto, estas son las tres rupturas de reglas que uso a propósito.

Excepción 1: JSONB para datos de verdad flexibles

PostgreSQL, el motor de base de datos que hay debajo de la mayoría de los productos SaaS modernos, tiene un superpoder llamado JSONB. Permite que una sola columna contenga un documento entero de formato libre: cualquier campo, cualquier forma, distinta en cada fila. Es la vía de escape del mundo estructurado.

Piensa en tu base de datos como en un archivador con cajones etiquetados. JSONB es el cajón etiquetado “varios”, y un cajón de varios es realmente útil, siempre que nunca se convierta en el lugar donde guardas el pasaporte. El contenido legítimo: cosas cuya forma no puedes conocer de antemano. Si tus usuarios crean formularios personalizados, cada envío tiene campos distintos: no puedes diseñar de antemano un cajón para campos que todavía no existen. Lo mismo vale para los campos personalizados definidos por el usuario, las preferencias y ajustes de cada usuario, las cargas que llegan de sistemas de otras empresas, los metadatos sueltos y las instantáneas de antes y después dentro de los registros de auditoría.

La regla de una frase que sigo:

Si necesitas conectarlo con otros datos, consultarlo con frecuencia o hacer cumplir relaciones, hazlo relacional. Si es flexible, definido por el usuario o rara vez se consulta, JSONB está bien.

La señal de que JSONB es seguro: los datos pertenecen a una sola fila y nunca se consultan con independencia de ella. Es exactamente la situación en la que no pueden darse los problemas de actualización que la estructura existe para evitar. La señal de que es un error: te pillas queriendo hacer preguntas a través del JSONB, “todas las tareas etiquetadas como urgentes”, “todos los pedidos de este cliente”. Eso son relaciones, y las relaciones pertenecen a las tablas.

12 semanasTu carrera corporativa nunca fue el planSolicita plaza en el Solopreneur Accelerator.Solicitar ahora →

Excepción 2: contadores que no puedes permitirte calcular en vivo

La estructura estricta dice: nunca almacenes lo que puedes calcular. El número de miembros de un canal, la valoración media de un anuncio, el número de candidaturas de una oferta de empleo: todo esto puede calcularse bajo demanda contando los registros subyacentes, y a pequeña escala eso es exactamente lo que debes hacer.

Luego llega la escala. Una comunidad en la que los canales tienen 100.000 publicaciones no puede recontarlas en cada renderizado de página. Un marketplace con 500.000 anuncios no puede recalcular las valoraciones medias dentro de cada resultado de búsqueda. Una bolsa de empleo en la que las empresas reciben 50.000 candidaturas no puede contarlas en vivo en cada visita al perfil. En ese punto almacenas el número, una columna de contador precalculada, y leerlo no cuesta nada.

Esta es la disciplina que evita que se pudra: todo contador almacenado necesita un mecanismo de mantenimiento, un trigger o una función de base de datos que lo actualice en el instante en que cambian los datos subyacentes. Un contador sin él no es una optimización; es una mentira esperando a que alguien se la crea. En mi esquema, cada columna de contador tiene un mecanismo documentado que la mantiene sincronizada, y las notas de diseño registran cuál y cuándo se dispara.

Un refinamiento que merece la pena copiar: los contadores de visitas son la excepción dentro de la excepción. Se actualizan de forma asíncrona (se lanzan desde la página después de cargarla) en lugar de mediante un trigger, de modo que contar visitas nunca ralentiza una página, se pueden filtrar los bots y se pueden deduplicar las visitas repetidas. Los contadores exactos (miembros, votos, candidaturas) llevan triggers; los contadores de vanidad reciben un trato más relajado.

Excepción 3: el dinero son siempre céntimos enteros

Esta es menos "romper una regla" que rechazar una opción por defecto que parece natural y es silenciosamente peligrosa. Almacenar 12,99 € como el número decimal 12,99 invita a la aritmética de coma flotante del ordenador a entrar en tus finanzas, y las matemáticas de coma flotante producen pequeños errores de redondeo que en un gráfico solo son feos pero en una factura son inaceptables.

La solución: almacena cada importe monetario como un número entero de céntimos. 12,99 € se guarda como 1299. Los números enteros no tienen errores de redondeo, nunca. Todo el sistema de pagos de Stripe habla esta convención (importes en la unidad monetaria más pequeña), así que tu base de datos coincide de forma nativa con tu proveedor de pagos. La división entre 100 ocurre solo en el último momento, en la capa de presentación, donde un error cuesta un fallo cosmético en lugar de dinero.

En mi esquema esto es absoluto: cada precio, comisión, propina y total son céntimos enteros. Sin decimales para el dinero, en ningún sitio, nunca.

La metarregla: las excepciones se escriben

Fíjate en lo que comparten las tres excepciones. Cada una tiene un desencadenante estrecho (forma imposible de conocer; coste medido del cálculo en vivo; la naturaleza del dinero). Cada una tiene un mecanismo compensador (la prueba del JOIN; los triggers de sincronización; la conversión en la capa de presentación). Y cada una está documentada: mi plataforma mantiene un archivo de decisiones de diseño con todas las desviaciones intencionadas, precisamente para que las auditorías futuras (humanas o de IA) distingan la ingeniería deliberada de la chapuza acumulada.

Esa es la verdadera diferencia entre una ruptura profesional de las reglas y la deuda técnica: una viene con una razón escrita, la otra viene con un encogimiento de hombros.

El libroThe Solopreneur RevolutionLuis Gonçalves sobre cómo crear un negocio de solopreneur con IA sin dejar tu empleo.Consigue el libro →

Preguntas frecuentes

¿JSONB es una mala práctica?

No: el JSONB mal usado es una mala práctica. Para datos de verdad flexibles y propios de una fila es la herramienta correcta y evita una complejidad inútil. El modo de fallo es usarlo para esquivar el diseño de la base de datos: meter etiquetas, responsables o relaciones en un blob JSON porque diseñar las tablas adecuadas parecía trabajo. Aplica la prueba del JOIN y JSONB seguirá siendo una herramienta en lugar de una trampa.

¿Cómo sé cuándo debe almacenarse un contador?

Cuando contar en vivo perjudica de forma medible (una página que recuenta grandes conjuntos de registros en cada renderizado) y no antes. Empieza calculando los recuentos bajo demanda; almacena un contador solo cuando la escala te obligue, y nunca sin el trigger o la función que lo mantiene exacto. Los contadores prematuros son complejidad inmerecida.

¿Por qué no usar simplemente una columna decimal para el dinero?

Porque los céntimos enteros hacen imposible, y no solo improbable, toda una clase de errores financieros, y porque tu proveedor de pagos ya piensa en la unidad monetaria más pequeña. Dos representaciones del dinero (céntimos en Stripe, decimales en tu base de datos) significan conversiones por todas partes, y cada conversión es un lugar donde equivocarte con la factura de alguien.

¿Qué pasa si uso JSONB para todo?

Obtienes una base de datos incapaz de responder preguntas. Sin relaciones, sin garantía de integridad, sin filtrado eficiente y con informes dolorosos: has reconstruido un montón de documentos con pasos extra. Flexibilidad que no necesitabas, comprada con la capacidad de consulta de la que vive tu negocio. Conserva la estructura para el 95 % y gasta JSONB donde la forma sea de verdad imposible de conocer.