Bueno, en el sistema que tengo desarrollado, hasta hace 6 meses tenia alrededor de 300 consultas SQL. Para escribir este post he checado que tengo mas e 450 consultas SQL entre Selects, Inserts Updates, Deletes.
Para mi seria un despelote y un dolor de cabeza recorrerme todo el código SQL mezclado con el codigo VB6, esto ya lo previ hace años y por eso opte a reunir todas las consultas SQL en módulos, de tal manera que :
1.- Cuando quiera ubicar una consulta especifica solo me concentro en un sector de busqueda.
2.- Me resulta mas legible leer el codigo VB sin "marearme" con el SQL siendo que algunas consultas SQL son enormes.
3.- Reutilizo parametrizando las consultas SQL
4.- La depuración o mantenimiento me resulta mas sencilla y rapida.
4.- Para armar reportes me es totalmente flexible hacer cambios en "caliente".
5.- A la larga gano muchismo tiempo y por lo tanto me vuelvo mas productivo.
Desventajas
Ayúdame a encontrar una. No me digas que el aplicativo crece, crece si, pero una nada y con el costo de las RAMs por los suelos ni vale la pena considerarlo.
Ahora, quiza hacer todo esto cobre sentido cuando uno tendra en su software una enorme cantidad de consultas, si uno va a tener alrededor de 50 consultas quiza no resulte beneficioso armar todo esto.
Empiezo asi:
Uso 4 modulos, ¿porque no usar solo uno? porque muchas veces hay cosas que solo requiere hacer copy paste y modificar algunas cosillas, entonces me resulta mas facil tomar la consulta siguiente o anterior del mismo modulo. Tambien lo hago porque cuando tengo que armar una consulta desde cero me es mas rapido ubicar una del mismo tipo, me resulta mas rapido.
Entrando un poco mas, por ejemplo entro al modulo donde solo tengo puros SELECTS de esta forma:
¿Porque llamo los campos de la forma que se ven? es tema de otro post y tambien tiene su sustento, la nemotecnia es parte de mi forma de programar.
Como pueden ver, las consultas las tengo parametrizadas, casi siempre, los parametros pueden ser valor o condiciones para tomar una parte de la consulta SQL. De tal manera que puedo excluir de la consulta algunos Where o aumentar otros.
Ahora si, lo unico que tengo que hacer es invocar de esta forma
Al rs le paso los parámetros y listo, la verdad esto lo veo mas limpio.
Otro ejemplo: Aqui armo un reporte... y no tengo una sola linea de código sql a la vista que me maree cuando lo que quiero ver es el puro codigo VB6
y si desde alli quisiera ver la consulta SQL solo tengo que darle a la funcion "Definir" asi:
Y de esa forma chequeo la consulta SQL
Otro ejemplo, lo mas lindo es cuando tengo que insertar a varias tablas con diversas validaciones todo en un solo proceso. Aqui un extracto:
y los inserts siguen mas abajo, no se ustedes pero para mi ver alli mismo todo el código SQL me marearia.
Bien, si aun no queda claro lo que quiero explicar que vengan las preguntas.
Ojo, Insisto, Recalco y Subrayo que no quiero decir con esto que estoy explicando sea LA FORMA de hacer las cosas, es solo un método que a mi me sirvio y me va muy bien, y asi pasen años mantener el código no me presenta complicación en su estructura y solo me concentro en el fondo del problema a resolver, los beneficios son claros.
Se que hay de los que se tiran unas enormes sabanas donde mezclan el código VB6 y SQL y ya los veo haciendo PGDN y PGUP y agudizar la vista para ubicar lo que quieren ubicar, si ellos se sienten mejor asi, si se sienten mas productivos, mas ordenados, pues bien por ellos, ¿quien soy yo para cambiarles sus formas? jeje, pero si a alguien se le adecua esta forma pues me avisa y le suelto unos tips mas (siempre por este medio).
Próximamente: Vídeo FirebirdSQL (No lo veannnn jajaj, tu entiendes el chiste Fx700)
