"La optimización prematura es la raíz de todo mal (de todos modos, la mayoría) en la programación de computadoras" - Donald Knuth
La base de datos es exactamente eso; La capa de datos de su aplicación. Su trabajo es proporcionar a su aplicación los datos solicitados y almacenar los datos que se le han proporcionado. Su aplicación es el lugar para colocar el código que realmente funciona con los datos; desplegándolo, validándolo, etc.
Si bien el sentimiento en la línea del título es admirable y preciso hasta cierto punto (el meollo de la acción de filtrar, proyectar, agrupar, etc. debería en el abrumador número de casos debe dejarse en el DB) , una definición de "bien" podría estar en orden. Las tareas que SQL Server puede ejecutar con un alto nivel de rendimiento son muchas, pero las tareas que puede demostrar que SQL Server hace correctamente de manera aislada y repetitiva son muy pocas. SQL Management Studio es una gran base de datos IDE (especialmente teniendo en cuenta las otras opciones con las que he trabajado, como TOAD), pero tiene sus limitaciones, entre las que se encuentra que casi todo lo que se usa para hacer (o cualquier código de procedimiento que ejecute en la base de datos que se encuentra debajo) es, por definición, un "efecto secundario" (el estado de alteración se encuentra fuera del dominio del espacio de memoria de su proceso). Además, el código de procedimiento dentro de SQL Server es solo ahora, con los IDE y las herramientas más recientes, que se pueden medir de la manera en que el código administrado puede usar métricas de cobertura y análisis de ruta (por lo que puede demostrar que esta declaración particular si es encontrada por las pruebas) , Y, y Z, y la prueba X está diseñada para que la condición sea verdadera y se ejecute esa mitad, mientras que Y y Z ejecutan el "más". Eso, a su vez, supone que tiene una prueba que puede configurar la base de datos con un inicio en particular Estado, ejecute el código de procedimiento de la base de datos a través de alguna acción y confirme los resultados esperados.
Todo esto es mucho más difícil e involucrado que la solución provista por la mayoría de las capas de acceso a datos; asuma la capa de datos (y, para el caso, el DAL) sepa cómo hacer su trabajo cuando se le da la entrada correcta, y luego pruebe que su código proporciona la entrada correcta. Al mantener el código de procedimiento como los SP y los activadores fuera de la base de datos y, en su lugar, hacer ese tipo de cosas en el código de la aplicación, dicho código de la aplicación es mucho más fácil de ejercer.