SQL es un poderoso lenguaje de programación y es muy bueno para lo que fue hecho, consultas de conjuntos de datos. C#, Java y otros lenguajes son también poderosos, más poderosos que SQL en muchas formas. Para bucles y tareas en forma de procedimientos, C# puede procesar cientos de registros muchas veces más rápido que un cursor SQL, e incluso hacerlo en unas líneas de código más escasas. SQL simplemente no fue hecho para hacer ese tipo de procesamiento. En vez de eso, SQL fue hecho para procesar conjuntos de datos donde las tablas y conjuntos de resultados son utilizados y combinados en base a condiciones.
De manera similar, SQL es de lejos la interfaz de usuario que uno quiere tener. Muchas tareas que necesitan una interfaz de usuario, no son apropiadas para la lógica SQL. Por ejemplo, si los nombres de clientes deberían aparecer en una rejilla web con el formato [nombres],[apellido paterno][apellido materno], una opción es retornar los datos desde una sentencia SQL con ese formato. Sin embargo, un método más apropiado es simplemente retornar las partes del nombre, y que la lógica en la interfaz de usuario formatee el nombre completo en el formato deseado.
Algunos puntos para tomar en cuenta:
1. ¿Qué pasa si la capa de negocios o la interfaz de usuario está bloqueada y la única forma de cambiar el formato es cambiar los datos que se carga?
2. ¿Qué pasa si en vez de que los datos sean llamados por una aplicación o sólo un sitio web, sean llamados por 2 o 3 aplicaciones web, y estén disponibles como un servicio web, y de paso por una aplicación de consola? Mientras que en teoría un componente de negocios puede ser desarrollado para manejar todas esas llamadas, una opción más fácil es simplemente centralizar a nivel de base de datos en un procedimiento almacenado la salida de datos.
3. ¿Qué pasa si los resultados necesitan ser llamados por otra pieza de lógica SQL? Podría ser transformados en una vista.
4. ¿Qué pasaría si el resultado está destinado a mostrarse como un archivo de Excel que será rápidamente modificado ya que el usuario pide un reporte personalizado? ¿Qué pasa si ellos solicitan otra vez una pequeña modificación de la lógica unos cuantos minutos después que finalices de modificar el formato del archivo de Excel? ¿No podría ser más fácil tener la lógica en el SQL en este caso?
5. ¿Qué sucede si el desarrollador que escribió la lógica es simplemente más adepto a una solución basada en SQL para lo que se necesita?
Para mi, si algo puede ser hecho en forma de conjuntos de datos, trato de hacerlo en SQL para terminar el trabajo, en todo lo que sea posible que pueda ser hecho en forma de conjuntos de datos, vayamos a la lógica SQL (y todo lo que requiera lógica de procedimientos va en el código).
¿Que dices tú?
No hay comentarios:
Publicar un comentario