Cita: Quieres decir que le concierne, pero que no lo hace...Ah...Pues entonces, alguien tendrá que hacerlo, no?
Si. Pero ese alguien definitivamente no es la aplicación.
Ese alguien es una Capa de Abstraccion de la Base de Datos (aka DBAL) que suple las falencias del motor de turno.
No hay sentido a reinventar la rueda, si el motor sabe hacerlo que lo haga, si no sabe se le emparcha, pero emparchar porque quizás mañana cambie el motor no es (a mi criterio) una opción valida.
Me remito a un principio del modelo de desarrollo incremental de agilismo:
Cita: La definición de un ítem se puede postergar hasta en momento en el cual se decide abordar el ítem. Esto favorece la resistencia al cambio, pues no se necesita hacer inversión de esfuerzo con anticipación. Mientras más tiempo hay entre la definición y la ejecución de un ítem, más riesgo existe que dicha definición caduque o que el ítem pierda prioridad.
Traducido a este caso: Si la base de datos de turno puede chequear y validar integridad de tipo y dominio de la forma que sea, que lo haga. Si el dia de mañana cambia la base de datos, se emparcha y todo sigue funcionando.
Si la base actual soporta dominios y la nueva no, se tendra que implementar con triggers.
Si la base actual soporta triggers y la nueva base de datos no soporta triggers ni herramientas equivalentes, la dbal tendra que implementarlos por su cuenta.
La aplicación ni se entero, ella sigue dialogando con la dbal.
En la practica la base de datos se recarga con querys fallidas? La dbal tendra que empezar a validar antes para quitarle carga.
Soluciones concretas a problemas concretos.
Resumiendo y sin retoricas para que entiendas mi punto: Si hoy la base de datos puede validar ella, que lo haga. Si mañana no puede se buscara una solución mañana. Soluciones simples y rapidas a problemas cotidianos, soluciones complejas y lentas a problemas aislados.