Yo soy del lado de "ignorar lo que puede hacer un RDBMS dizque porque eso nos amarra" no tiene sentido, pero a la vez, tampoco es bueno "cambiemos las cosas, no sé porque, pero
hagale!".
Si miramos un app con rdbms al estilo "OO" en capas (UI, controladores, vistas, modelos, logica, manejo datos, ..) veríamos que OO es *
deficiente* en "manejo de datos" y parcialmente en "logica y modelos". Para ello hay que tener CLARO cual es el fuerte de un rdbms bajo el modelo RELACIONAL:
- Definir estructuras de datos (tablas)
- Definir un conjunto de operaciones sobre esas estructuras (operaciones relacionales)
- Establecer las reglas de operar sobre esos datos ("validaciones").
Si cae en eso, tiene sentido ponerlo en la BD. A diferencia de la mentalidad
anterior que creía que "es mas importante abstraer la BD, porque imaginate si no sabemos cuándo nos da por cambiarnos?" ahora es claro que los RDBMS sobreviven MAS a los lenguajes que los acceden. Yo tengo un app, que lo tocan/tocaron como 5 diferentes lenguajes (que han ido cambiando en el tiempo), mientras la BD es basicamente la misma con mejoras, y de hecho, cada vez se optimiza para que sea MAS independiente de los "front end".
PERO
Hay que tener cuidado de meter logica de "app" dentro de la BD. Una buena BD es "agnostica".
Osea: Al contrario de decir: Hago mi codigo en Delphi agnostico a la BD, que no tiene sentido el 90% de la veces (excepto si hago un administrador de BD o un driver de BD), debo pensar: Hago mi BD agnostica, y luego implemento lo especifico en Delphi ( o lo que sea). Si mis tablas, vistas, procedimientos, etc estan bien hechos, se adaptaran de forma natural a lo que tire encima.
ASI ES COMO SE PENSO EL MODELO RELACIONAL.
Este fue unos de los grandes aciertos cuando se creo. Porque ANTES de los rdbms, TODO ACCESO A DATOS ERA HECHO DENTRO DE LOS LENGUAJES y no se compartia ni logica de datos (malo) ni menos, datos (remalo).
Asi que:
Diseña tu BD de forma tal que puedas decir: "Como le invente una consulta a esto, funciona" y programas los triggers, procedimientos, etc que validen DATOS (que sea unico, que no este vacio, que sume , que reste), y deja lo concreto (formularios, reportes, etc) en Delphi.