Siempre que sea posible, es recomendable que la lógica del sistema [1] esté a la mayor profundidad posible en la arquitectura del sistema. Esto significa que es mejor hacer que las funciones de la lógica se encuentren en una capa intermedia antes que en la capa de presentación, y que es preferible que las ejecute el sistema de gestión de bases de datos (SGBD) antes que la capa intermedia.
Así como la independencia de la capa de presentación es una convención de las arquitecturas a tres capas, el uso del gestor de bases de datos para mantener la lógica del sistema no suele plantearse como alternativa. No obstante, existen ventajas inherentes a la adopción de esta decisión.
En primer lugar, los gestores de bases de datos tienen su propia capa de seguridad, que no es necesario reinventar en capas intermedias; como contrapartida, dependerá del licenciamiento del gestor para que merezca la pena. Por otro lado, se evitan funciones de la lógica que simplemente hacen de interfaces con el SGBD y que podrían implementarse fácilmente mediante un procedimiento almacenado (práctica que sí es recomendable, en cualquier lugar en el que se encuentre la lógica); en muchos proyectos, la mayoría de los métodos no tienen otra función que la de enviar solicitudes al SGBD y devolver el resultado tal cual. Por último, los recursos empleados para el proyecto disminuyen notablemente, al tratar básicamente la capa de interfaz de usuario y el SGBD.
Sin embargo, no siempre es posible sumergir la lógica del sistema. Generalmente esto se debe las limitaciones de los SGBD y de sus lenguajes de programación: los lenguajes script SQL no suelen ser demasiado amigables para un desarrollo complejo [2]. Por otro lado, sumergir la lógica puede requerir publicar la máquina en la que se encuentra el SGBD, siendo necesaria una capa intermedia para evitarlo y cuya función sería simplemente trasladar la solicitud del usuario al gestor de bases de datos y devolver la respuesta.
[1] Entendemos "lógica del sistema" como la parte de éste donde se encuentran las funciones que resuelven las solicitudes de envío y transformación de datos, y que no son tareas propias de las interfaces de usuario ni de datos.
[2] Microsoft® permite programar su SGDB SQL Server® en lenguajes .NET (C#, por ejemplo). Es una alternativa interesante para sumergir la lógica, aunque supone la dependencia de los sistemas de la empresa.
