Consulta para pasar codigo delphi a SQL

[Neftali [Germán.Estévez]]

Empezado por ingel

...necesito comenzar a quitar codigo fuente de mis aplicaciones Delphi 7 , especificamente todo lo referido a los accesos a datos y pasarlos a la Base de Datos SQL.

Personalmente me parece bien utilizar las propiedades de la Base de Datos cuando haga falta. Y pasar código a una Base de Datos cuando necesitemos mayor rendimiento o velocidad. Sobre todo pensando en operaciones grandes y complejas que se puedan pasar a un Stored Procedure.
Pero llevar esto al extremo tampoco no me parece lógico, a no ser que exista una razon que no explicas aquí.

Empezado por ingel

... porque los INSERT , DELETE y UPDATE en su mayoria estan hechos con Store Procedures y solo les paso los parametros.

¿Qué ventaja tiene lanzar un UPDATE desde un Query a lanzar un SP con parámetros que haga el UPDATE?
En consultas normales la diferencia de tiempo entre ambos debe ser despreciable y en ese caso estamos complicando la programación y "atándonos" aun gestos de Bases de Datos de una forma muy fuerte.
O un DELETE, crear un SP para hacer un DELETE ¿tiene sentido? Yo sin más datos no lo veo.

Empezado por ingel

... Entiendo que deberia reemplazar los SELECT por VISTAS o con SP tambien podria hacerlo ?

Las vistas son para lo que son. Lo mismo de antes. ¿Una SELECT NORMAL, qué sentido tiene reemplazarla por una vista o un SP?

Empezado por ingel

La idea es dejar el menor codigo posible del lado de la aplicacion.

Lo mismo. ¿Cual es el sentido de esto?
Me he encontrado algun caso en que hacer debug de un SP era un calvario, porque las herramientas o los IDE de las Bases de Datos a la hora de hacer Debug son básicos o inexistentes y en cualquier caso no llegan a los de un IDE como Delphi.
Por lo tanto cuando hay que usar un SP porque no hay otro remedio me parece bien, pero usarlos de forma generalizada lo veo un atraso.

Lo dicho tal vez me faltan datos, pero me gustaría entender la razón de hacer esto que planteas.

Comentar también que "mis dudas" están provocadas porque al final, lo que debería ser estandard (pienso en el lenguaje SQL), cuando trabajas con diferentes Base de Datos, te das cuenta de que no lo es. Ya no sólo Stored Procedures (con leguaje propio), sino hasta las propias SELECT (que consideramos lo más simple) son diferentes en diferentes motores.
Por lo tanto algo como lo que planteas, te ataría de por visa a un único motor de Base de Datos.