Cuando reviso los modelos de base de datos para RDBMS, generalmente me sorprende encontrar pocas o ninguna restricción (aparte de PK / FK). Por ejemplo, el porcentaje a menudo se almacena en una columna de tipo int
(mientras que tinyint
sería más apropiado) y no hay una restricción CHECK
para restringir el valor a un rango de 0..100. De manera similar, en SE.SE, las respuestas que sugieren restricciones de verificación a menudo reciben comments sugiriendo que la base de datos es el lugar incorrecto para las restricciones.
Cuando pregunto sobre la decisión de no implementar restricciones, los miembros del equipo responden:
-
O que ni siquiera saben que tales características existen en su base de datos favorita. Es comprensible para los programadores que usan ORM solamente, pero mucho menos para los DBA que afirman tener más de 5 años de experiencia con un RDBMS dado.
-
O que apliquen dichas restricciones en el nivel de la aplicación, y duplicar esas reglas en la base de datos no es una buena idea, violando SSOT.
Más recientemente, veo más y más proyectos donde ni siquiera se usan claves externas. Del mismo modo, he visto algunos comentarios aquí en SE.SE que muestran que a los usuarios no les importa mucho la integridad referencial, permitiendo que la aplicación la maneje.
Cuando le preguntan a los equipos sobre la opción de no usar FK, dicen que:
-
Es PITA, por ejemplo, cuando uno tiene que eliminar un elemento al que se hace referencia en otras tablas.
-
NoSQL oscila, y no hay claves foráneas allí. Por lo tanto, no los necesitamos en RDBMS.
-
No es un gran problema en términos de rendimiento (el contexto suele ser pequeñas aplicaciones web de intranet que trabajan con conjuntos de datos pequeños, por lo que incluso los índices no importan demasiado; a nadie le importaría si el rendimiento de un La consulta dada pasa de 1.5 s a 20 ms.)
Cuando miro la aplicación en sí, me doy cuenta sistemáticamente de dos patrones:
-
La aplicación limpia correctamente los datos y los verifica antes de enviarlos a la base de datos. Por ejemplo, no hay manera de almacenar un valor
102
como porcentaje a través de la aplicación. -
La aplicación asume que todos los datos que provienen de la base de datos son perfectamente válidos. Es decir, si
102
aparece como un porcentaje, o algo, algún lugar se bloqueará o simplemente se mostrará al usuario, lo que dará lugar a situaciones extrañas. -
Si bien una sola aplicación realiza más del 99% de las consultas, con el tiempo comienzan a aparecer los scripts, ya sea que los scripts se ejecuten a mano cuando sea necesario, o los trabajos cron. Algunas operaciones de datos también se realizan a mano en la propia base de datos. Tanto los scripts como las consultas manuales de SQL tienen un alto riesgo de introducir valores no válidos.
Y aquí viene mi pregunta:
¿Cuáles son las razones para modelar bases de datos relacionales sin restricciones de verificación y, finalmente, incluso sin claves externas?
Por lo que vale, esta pregunta y las respuestas que recibí (especialmente la interesante discusión con Thomas Kilian) me llevaron a escribir una Artículo con mis conclusiones sobre el tema de las restricciones de la base de datos .