Entrevista de ingeniería de datos: ¿Qué problema resuelve NOT ENFORCED en PostgreSQL 18?

Planteamiento y escenario

Una tabla heredada orders contiene una pequeña cantidad de valores customer_id sin un cliente principal. El equipo desea declarar la relación en PostgreSQL 18 para que el esquema de destino sea explícito, sin bloquear una reparación única de datos históricos. Decida si NOT ENFORCED es adecuado, explique en qué se diferencia de una clave foránea normal, muestre cómo encontrar infracciones y defina una transición por etapas junto con la evidencia de que los datos están listos.

Lo que evalúa el entrevistador

Distinguir entre una intención de negocio declarada y el rechazo de escrituras no válidas por parte de la base de datos.
Explicar que NOT ENFORCED no verifica las escrituras y, por lo tanto, no constituye una garantía completa de integridad en tiempo de ejecución.
Diseñar escaneos históricos, monitoreo incremental, lotes de reparación y una compuerta de transición final.
Identificar riesgos asociados con volcados, restauraciones, emisores de escritura entre servicios, reversiones y compatibilidad de clientes.
Explicar por qué una restricción no verificada no debe tratarse como una suposición válida para el optimizador de consultas.

Preguntas de aclaración antes de responder

¿Se trata de una clave foránea o de un CHECK? ¿Cuál es el volumen de infracciones, la tasa de crecimiento y el responsable de la reparación?
¿Las escrituras se limitan a PostgreSQL o existen trabajos de ETL, scripts por lotes y herramientas directas que eluden la aplicación?
¿Los clientes heredados pueden manejar el nuevo nombre de restricción, el bloqueo de migración y una transición fallida?
¿La transición final debe alcanzar cero infracciones o puede completarse inquilino por inquilino?
¿Qué evidencia demuestra que se escanearon todas las particiones y marcas de agua?

Estructura de respuesta de 30 segundos

“NOT ENFORCED es útil para declarar la intención de un CHECK o una clave foránea mientras aún existan datos heredados no depurados; PostgreSQL no validará las nuevas escrituras para dicha restricción, por lo que no es una garantía de integridad. Establecería una línea base completa de infracciones, ejecutaría verificaciones incrementales y alertas para nuevas escrituras, repararía o pondría en cuarentena las filas históricas y cambiaría a enforced únicamente tras obtener cero infracciones y realizar un simulacro de restauración. Durante la transición, ni los clientes ni los optimizadores deben tratar la declaración como una verdad comprobada.”

Respuesta detallada paso a paso

Exponer la semántica y el riesgo

PostgreSQL 18 permite especificar restricciones CHECK y de clave foránea como NOT ENFORCED. La base de datos almacena la declaración, pero no valida las escrituras como lo haría con una restricción aplicada (enforced). Los metadatos respaldan la documentación, la gobernanza y la coordinación de la migración; no reemplazan las validaciones de calidad de datos independientes, de ETL o de la aplicación.

Construir evidencia completa e incremental

Para una clave foránea, ejecute un anti-join para encontrar filas secundarias sin un elemento principal; para un CHECK, ejecute la negación del predicado. Registre el tiempo de escaneo, la instantánea o marca de agua, el rango de partición y un resumen del resultado. Luego, verifique las inserciones y actualizaciones en CDC, trabajos de escritura o tareas de calidad, de modo que un escaneo histórico único no oculte una nueva ruta de elusión.

sql

SELECT o.order_id, o.customer_id
FROM orders AS o
LEFT JOIN customers AS c ON c.customer_id = o.customer_id
WHERE o.customer_id IS NOT NULL
  AND c.customer_id IS NULL;

Diseñar compuertas de reparación y transición

Clasifique las órdenes huérfanas en: reparables automáticamente, que requieren confirmación del negocio o que requieren cuarentena. Asigne a la reparación una clave de idempotencia, un límite de lote y una condición de parada. Antes de cambiar, exija un escaneo completo en cero, una ventana incremental limpia, un simulacro exitoso de copia de seguridad y restauración, y cobertura de todos los emisores de escritura. Ejecute la migración enforced en una ventana de bajo tráfico y supervise las esperas de bloqueo y las tasas de error.

Manejar la recuperación y la desviación de entornos

Si la migración falla, mantenga la declaración NOT ENFORCED y los registros reparados, revierta el despliegue de la aplicación y el trabajo de calidad, y no asuma que la restricción está aplicada. Pruebe volcados, restauraciones, réplicas de lectura, clústeres de recuperación ante desastres y clientes antiguos. Confirme que los entornos de destino comprendan los metadatos de conenforced en lugar de depender únicamente de la visualización del ORM.

Ejemplo de respuesta de alta calidad

“Trato a NOT ENFORCED como un contrato de migración, no como una barrera de protección de la base de datos. Ejecutaría un anti-join completo entre órdenes y clientes, registraría particiones y marcas de agua, y luego dejaría que CDC verifique las nuevas escrituras. Las filas huérfanas se clasifican en reparación automática, confirmación del negocio y cuarentena, con reproducción idempotente. Solo después de que las comprobaciones completas e incrementales estén limpias, se supere la prueba de restauración y se cubran todos los emisores de escritura, cambiaría la clave foránea a enforced en una ventana de bajo tráfico y monitorearía las esperas de bloqueo. En ningún momento un cliente o un optimizador de consultas asumiría que la declaración demuestra integridad.”

Errores comunes

Error: Ver una clave foránea en el esquema y asumir que los datos son consistentes → Por qué falla: NOT ENFORCED no verifica las escrituras → Corrección: Producir evidencia de calidad completa e incremental.
Error: Escanear la tabla histórica una sola vez → Por qué falla: Un nuevo proceso de escritura no controlado puede generar infracciones → Corrección: Cubrir CDC, ETL, scripts y escrituras de aplicaciones.
Error: Cambiar directamente a enforced → Por qué falla: Los datos no depurados o los bloqueos pueden abortar la migración → Corrección: Reparar, ensayar, validar compuertas y luego cambiar en una ventana de bajo tráfico.
Error: Tratar una declaración no aplicada como una sugerencia de optimización → Por qué falla: Una declaración no es una prueba de integridad → Corrección: Confiar únicamente en estadísticas verificadas y en el comportamiento admitido por la base de datos.

Preguntas de seguimiento y respuestas

¿Puede una restricción CHECK hacer referencia a otra tabla para una regla entre tablas?

No confíe en ello. Un CHECK a nivel de fila no puede garantizar una condición global después de que otras filas cambien, y el orden de volcado/restauración puede exponer la falla. Prefiera una clave foránea o una tarea de calidad independiente para relaciones entre tablas.

¿Qué sucede si el recuento de infracciones nunca llega a cero?

Mantenga NOT ENFORCED, coloque las infracciones en cuarentena o en una lista explícita de excepciones de negocio, y defina un límite de crecimiento, un responsable y una fecha de caducidad. Si la restricción es meramente documentación y no un contrato ejecutable a corto plazo, reevalúe si corresponde mantenerla en el esquema.

¿Puede la validación en la aplicación reemplazar una clave foránea aplicada?

Solo como una medida de transición o complementaria. Múltiples emisores de escritura, la concurrencia y los scripts directos eluden las validaciones de la aplicación; el límite final de integridad debe ser una restricción de base de datos o una canalización de datos verificable.

¿Cómo demuestra que una réplica de recuperación ante desastres no ha sufrido desviaciones?

Ejecute la misma consulta de calidad en la base de datos principal y en las réplicas restauradas, compare marcas de agua, recuentos de infracciones y resúmenes de resultados, e incluya simulacros de restauración en la compuerta de transición.

Referencias

Documentación de PostgreSQL 18: Restricciones
Documentación de PostgreSQL 18: CREATE TABLE
Documentación de PostgreSQL 18: Notas de la versión
Greg Low: Entrevista de SQL: 64 Deshabilitar y volver a habilitar restricciones
MockIF: Preguntas de entrevista de SQL 2026

Consejo para responder

Mencione que NOT ENFORCED declara una restricción sin verificar las escrituras, y luego detalle la línea base, el monitoreo incremental, las clases de reparación, la compuerta de transición y la evidencia de restauración.

Conclusión en una sola frase

NOT ENFORCED es un contrato de migración visible; los ingenieros de datos aún necesitan evidencia independiente antes de adoptar una protección obligatoria en tiempo de ejecución.