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 tinyintque sería más apropiado) y no hay ninguna CHECKrestricción para restringir el valor al rango 0..100. De manera similar en SE.SE, las respuestas que sugieren restricciones de verificación a menudo reciben comentarios que sugieren 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 únicamente, pero mucho menos para los DBA que afirman tener más de 5 años de experiencia con un RDBMS determinado.
O que imponen tales restricciones a nivel de 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 en los que 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 lo maneje.
Cuando preguntan a los equipos sobre la opción de no usar FK, les dicen que:
Es PITA, por ejemplo, cuando uno tiene que eliminar un elemento al que se hace referencia en otras tablas.
NoSQL es genial, 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 en pequeños conjuntos de datos, por lo que incluso los índices no importarían demasiado; a nadie le importaría si el rendimiento de una consulta determinada pasa de 1,5 s . a 20 ms.)
Cuando miro la aplicación en sí, noto sistemáticamente dos patrones:
La aplicación desinfecta adecuadamente los datos y los verifica antes de enviarlos a la base de datos. Por ejemplo, no hay forma de almacenar un valor
102como porcentaje a través de la aplicación.La aplicación supone que todos los datos que provienen de la base de datos son perfectamente válidos. Es decir, si
102viene como un porcentaje, algo, algún lugar se bloqueará, o simplemente se mostrará como es para el usuario, dando lugar a situaciones extrañas.Si bien más del 99% de las consultas las realiza una sola aplicación, con el tiempo, los scripts comienzan a aparecer: los scripts se ejecutan a mano cuando es necesario o los trabajos cron. Algunas operaciones de datos también se realizan manualmente en la 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 eventualmente incluso sin claves foráneas?
Por lo que vale, esta pregunta y las respuestas que recibí (especialmente la interesante discusión con Thomas Kilian) me llevaron a escribir un artículo con mis conclusiones sobre el tema de las restricciones de la base de datos .