Desde mi punto de vista, esto puede suponer una locura total y una falta de forma en lo que respecta al uso de un almacén de datos visto como tal. No obstante, hay sistemas de base de datos que implementan una capa de negocio bastante interesante, donde otros sistemas solo dan una opción de scripting que da algo de miedo.
En postgresql, por ejemplo, el sistema de lenguajes que se pueden usar e implementar para la creación de funciones: PL/pgSQL, PL/Tcl, PL/Python, PL/Perl, PL/PHP, PL/Java, PL/Ruby, ...; todos ellos se pueden ver en la página de documentación de PostgreSQL.
Esto quiere decir que, en una llamada a una función SQL se puede emplear una función específica programada en cualquiera de estos lenguajes, así como el lanzamiento de un trigger, puede ser compuesto por una serie de llamadas a estos procedimientos.
No obstante, la gente suele tener bastante miedo a usar estos sistemas para lógica de negocio por varios motivos, pero principalmente porque el despliegue es complejo.
Sí, en ciertos SGBD, un despliegue y mantenimiento resulta algo complejo, el hecho de mantener unas versiones y saber exactamente qué hay en producción y qué no hay, así como el hecho de que un cambio pueda hacerse en cualquier momento y pueda desvirtuar lo que haya en el repositorio en sí.
No obstante, puede solventarse con el uso de sistemas como migrations de rails, o similares. Es decir, no cargar nada directamente desde una interfaz abierta o desde la consola, sino desde una herramienta que permita controlar las subidas en forma de versiones.
En sí, el sistema de CHECK de PostgreSQL permite y da ventajas al usuario de desarrollar parte de la lógica de negocio. Allá donde no llegan los mecanismos típicos, es donde se puede comenzar a tirar de las funciones desarrolladas en cualquier lenguaje, con la potencia de que estas pueden ser lanzadas como CONSTRAINT, TRIGGERS o de forma inmediata en una consulta SQL.
En mi opinión, el uso de PostgreSQL como capa de datos, y además como capa de negocio, es una opción tan válida como extraer esa lógica a otros sistemas externos. La única nota negativa, es la interconexión, que obliga a que se haga con el conector de base de datos mientras que desarrollando la capa de negocio en otro tipo de framework, este acceso podría bien ser por mecanismos más orientados a RPC como SOAP o REST.
