Tema: data-modelling
-
Diseñar una tabla de series temporales de solo inserción en PostgreSQL
Almacenar las mediciones en una tabla particionada por rango de tiempo con timestamptz, una clave compuesta de serie y tiempo, índices ajustados al patrón de consulta (B-tree por serie, BRIN para recorridos de tiempo sobre toda la tabla) y una retención implementada separando y eliminando particiones en lugar de usar DELETE; estas decisiones se derivan de que las filas llegan en orden temporal y se eliminan en bloques temporales completos.
-
Dimensiones de cambio lento: sobrescribir, añadir una fila o añadir una columna
Cuando cambia un atributo de dimensión (un cliente se muda, un producto se reclasifica), el tipo 1 sobrescribe y pierde el historial, el tipo 2 añade una fila nueva con fechas de vigencia y expiración y un indicador de fila actual bajo una nueva clave subrogada, y el tipo 3 conserva el valor anterior en una columna adicional. Las herramientas de snapshot implementan el tipo 2 comparando una marca de tiempo de actualización o un conjunto de columnas en cada ejecución.
-
Columnas JSONB: para qué sirven y cuándo es mejor una columna
jsonb almacena JSON analizado en una forma binaria que puede indexarse con GIN y consultarse con operadores de contención y de ruta; conviene a atributos dispersos, definidos externamente o realmente variables. Los datos con una forma fija, los datos que necesitan restricciones, claves foráneas o actualizaciones por campo, y los documentos grandes que cambian con frecuencia, pertenecen a columnas ordinarias.
-
Registros de consentimiento y preferencias como datos: qué se eligió, cuándo y a través de qué superficie
Modelar las elecciones de una persona como eventos de solo anexado (sujeto, propósito, elección, momento, fuente, versión del texto) con una vista de estado actual derivada que cada consumidor lee en el punto de uso; un booleano en la fila del usuario no puede responder qué se acordó en el momento de una acción dada, ni a qué usuarios afectó un error del banner.
-
La minimización de datos como disciplina de esquema y de registro
Almacenar solo los datos personales que una funcionalidad necesita, con la precisión más gruesa que la sirva, y mantener los identificadores fuera de los registros (logs) mediante listas de permitidos (allowlist) de campos; cada columna, campo de registro y almacén derivado que contenga datos personales es una decisión de diseño con un propósito, una persona responsable y una caducidad, no un valor por defecto.
-
Borrado lógico frente a tablas de archivo
Un borrado lógico conserva la fila con una marca deleted_at, de modo que cada consulta debe filtrarla y cada restricción de unicidad debe convertirse en un índice parcial; una tabla de archivo saca la fila de la tabla activa, así las consultas sobre datos vigentes siguen siendo simples y el historial queda en un solo lugar. La elección depende de quién lee los datos borrados y con qué frecuencia, y debe plasmarse en restricciones y vistas, no en cada consulta.
-
Normalización hasta la tercera forma normal y cuándo desnormalizar
Las formas normales eliminan los grupos repetitivos y los datos almacenados en más de un lugar; la tercera forma normal exige que toda columna no clave dependa de la clave y de nada más. Lo recomendable es normalizar por defecto los datos transaccionales y desnormalizar solo en columnas derivadas con nombre propio, manteniendo normalizada la fuente de verdad.
-
Restricciones declarativas en PostgreSQL: CHECK, UNIQUE y claves foráneas con ON DELETE
Las restricciones hacen que la base de datos rechace estados no válidos para cualquier escritor, no solo para la aplicación: CHECK para reglas por fila, NOT NULL para valores obligatorios, UNIQUE para la identidad y claves foráneas con una acción ON DELETE explícita. Elegir la acción referencial e indexar la columna que referencia son las dos decisiones que más se omiten.
-
Fundamentos del esquema en estrella: hechos, dimensiones y declaración de la granularidad
Un esquema en estrella guarda las mediciones en tablas de hechos y el contexto descriptivo en tablas de dimensiones enlazadas por claves. El diseño empieza declarando la granularidad (qué representa una fila de hechos), porque toda medida y toda dimensión deben ser coherentes con ella. Las medidas totalmente aditivas se suman en cualquier dimensión, las semiaditivas no a lo largo del tiempo, y las razones deben almacenarse como sus componentes.
-
Seudonimización frente a anonimización como técnicas de ingeniería
La seudonimización sustituye los identificadores directos por tokens y conserva una vía de retorno (una clave o una tabla de correspondencias), de modo que sigue habiendo un registro por persona; la anonimización busca eliminar para cualquiera la asociación entre registros y personas. Para los seudónimos conviene usar HMAC con clave por finalidad, y tratar una tabla seudonimizada como datos personales, ya que conserva cuasi-identificadores.
-
Columnas de identidad, secuencias y por qué los IDs generados tienen huecos
Las columnas de identidad son la forma estándar de numerar filas automáticamente en PostgreSQL; toman sus valores de una secuencia cuyos valores se reparten fuera del control transaccional, así que los rollbacks, las caídas, el caching y los INSERT con ON CONFLICT dejan huecos. Los huecos son normales; una numeración sin huecos requiere un contador aparte y serializado.
Legible por máquina: JSON