Mejores Prácticas para Escenarios de Defectos
Cambios de esquema post-mortem en reglas de lint. Cada defecto de modelado que se convirtió en un incidente debería dejar una verificación de CI o una puerta de revisión detrás.
Cómo Usar Esta Lista
- Después de cada incidente de datos, mapea la causa raíz a un elemento de la lista de verificación y automatiza cuando sea posible.
- Ejecuta pruebas de detección de huérfanos y de fixtures de fan-out diariamente en instantáneas de producción (sanitizadas).
- Incluye enlaces a escenarios de defectos en la plantilla de revisión de esquemas de PR.
- Revisa las reglas cuando las actualizaciones de versión mayor de PostgreSQL cambien el comportamiento de DDL.
A - Prevención en Tiempo de Diseño
- Requerir FK en cada
*_idque referencie a otra tabla. Las exenciones necesitan un comentario ADR en la migración. - Modelar M:N con tablas de unión antes de escribir consultas. Bloquear PRs que añadan columnas
tag1,tag2. - Usar
timestamptzpara instantes absolutos. Prohibir nuevostimestamp without time zonepara eventos de usuario en el linter. - Preferir
text+CHECKsobre ENUM para estados en evolución. Enum solo con ADR de conjunto cerrado. - Documentar el grano de hechos para tablas de informes. "Una fila por línea de pedido" en el comentario de la tabla.
B - Detección en CI y Trabajos
- Suite de consultas huérfanas: cero filas para cada relación FK. Ejecutar contra la actualización de staging diariamente.
- Prueba de fixture de ingresos por fan-out con totales conocidos. Afirmar que SUM coincide con el valor calculado manualmente.
- Pruebas negativas entre inquilinos por tabla de inquilino. El Inquilino A nunca ve las filas del Inquilino B.
- Analizar migraciones para
ADD VALUEen enums. Marcar para revisión de DBA y requisito de prueba de carga. - Regresión de
EXPLAINpara las 10 principales consultas de informes. La explosión del recuento de filas falla la CI.
C - Respuesta Operacional
- La plantilla de post-mortem incluye la categoría de causa raíz del esquema. Fan-out, huérfano, enum, zona horaria, filtro de inquilino faltante.
- Convertir los elementos de acción post-mortem en reglas de lint dentro de un sprint. Sin repetición de incidentes sin nueva puerta de control.
- Panel de calidad de datos para recuentos de huérfanos y determinantes duplicados. Tendencia al alza = página de guardia.
- Congelar DDL destructivo durante la recuperación de incidentes de integridad. Corregir datos antes de añadir restricciones.
- Registrar SQL de remediación en el ticket de incidente. Se convierte en runbook y fixture de prueba.
D - Cultura y Revisión
- La revisión del esquema incluye la sección "¿Cómo falla esto?". Referenciar páginas de escenarios de defectos por nombre.
- El DBA aprueba los cambios de tipo de columna de ruta crítica. Especialmente
timestampvstimestamptzy enum. - El grano de la capa semántica de BI es revisado por ingeniería de datos. Sin auto-unión sin documentación de grano.
- Los nuevos ingenieros leen los Fundamentos de Escenarios de Defectos en la semana uno de incorporación.
- Día de juego trimestral: inyectar filas huérfanas en staging, medir el tiempo de detección.
Preguntas Frecuentes
¿Cuál es la verificación automatizada de mayor ROI?
Detección de huérfanos mediante LEFT JOIN ... WHERE parent IS NULL para cada par FK: detecta FK faltantes y errores de aplicación de forma temprana.
¿Cómo hago lint a SQL en migraciones?
Usa sqlfluff, squawk o scripts personalizados que analicen CREATE TABLE para _id sin REFERENCES.
¿Debería producción tener trabajos de integridad programados?
Sí: consultas de solo lectura diarias con alertas. Más barato que incidentes de conciliación financiera.
¿Cómo priorizo qué defectos automatizar primero?
Ordenar por frecuencia y gravedad del incidente: fuga entre inquilinos, ingresos por fan-out, huérfanos, zona horaria, bloqueo de enum.
¿Pueden las reglas de defectos ralentizar el desarrollo?
Exenciones con caducidad para prototipos. Las rutas de producción no tienen exención sin la aprobación del VP.
¿Qué va en un ticket de lint post-mortem?
Descripción de la regla, SQL de ejemplo que falla, SQL de ejemplo que pasa, propietario, enlace al ID del incidente, nombre del trabajo de CI.
¿Cómo pruebo las reglas de zona horaria?
La CI establece TimeZone a America/New_York y UTC; afirmar que los mismos órdenes de filas timestamptz son consistentes.
¿Los esquemas ORM necesitan el mismo lint?
Sí: generar migraciones desde ORM aún sujetas a lint de SQL en los archivos de salida.
¿En qué se diferencian las pruebas de fan-out de las pruebas unitarias?
Utilizan fixtures de múltiples tablas con cardinalidades conocidas: nivel de integración, no repositorios mockeados.
¿Cuándo puedo omitir una verificación de defectos?
Nunca en rutas de producción de ingresos y autenticación. Las herramientas de administración internas aún necesitan verificaciones de aislamiento de inquilinos si son multi-inquilino.
Relacionados
- Fundamentos de Escenarios de Defectos - patrones de incidentes
- Explosión de Join por Fan-Out - grano agregado
- Claves Foráneas Faltantes - aplicación de FK
- Dolor de Migración de Enum - riesgo de DDL de enum
- Errores de Timestamp Sin Zona Horaria - estándar timestamptz
Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, y PostGIS 3.5+.