Consulta para pasar codigo delphi a SQL

[ingel]

Buendia , 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 . Basicamente todos los SELECT que hago mediante Querys , porque los INSERT , DELETE y UPDATE en su mayoria estan hechos con Store Procedures y solo les paso los parametros. No se si habria algo mas que se pudiera migrar a la DB. Entiendo que deberia reemplazar los SELECT por VISTAS o con SP tambien podria hacerlo ? o hay alguna otra forma/herramienta/metodologia nueva?
La idea es dejar el menor codigo posible del lado de la aplicacion. Cualquier sugerencia sera bienvenida.
Gracias-Sds-Que tengan un buen dia.

[Casimiro Notevi]

Pues llama a los procedure: "execute procedure xxxxxxx"

[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.

[mamcx]

Yo soy del lado de "ignorar lo que puede hacer un RDBMS dizque porque eso nos amarra" no tiene sentido, pero a la vez, tampoco es bueno "cambiemos las cosas, no sé porque, pero hagale!".

Si miramos un app con rdbms al estilo "OO" en capas (UI, controladores, vistas, modelos, logica, manejo datos, ..) veríamos que OO es *deficiente* en "manejo de datos" y parcialmente en "logica y modelos". Para ello hay que tener CLARO cual es el fuerte de un rdbms bajo el modelo RELACIONAL:

• Definir estructuras de datos (tablas)
• Definir un conjunto de operaciones sobre esas estructuras (operaciones relacionales)
• Establecer las reglas de operar sobre esos datos ("validaciones").

Si cae en eso, tiene sentido ponerlo en la BD. A diferencia de la mentalidad anterior que creía que "es mas importante abstraer la BD, porque imaginate si no sabemos cuándo nos da por cambiarnos?" ahora es claro que los RDBMS sobreviven MAS a los lenguajes que los acceden. Yo tengo un app, que lo tocan/tocaron como 5 diferentes lenguajes (que han ido cambiando en el tiempo), mientras la BD es basicamente la misma con mejoras, y de hecho, cada vez se optimiza para que sea MAS independiente de los "front end".

PERO

Hay que tener cuidado de meter logica de "app" dentro de la BD. Una buena BD es "agnostica".

Osea: Al contrario de decir: Hago mi codigo en Delphi agnostico a la BD, que no tiene sentido el 90% de la veces (excepto si hago un administrador de BD o un driver de BD), debo pensar: Hago mi BD agnostica, y luego implemento lo especifico en Delphi ( o lo que sea). Si mis tablas, vistas, procedimientos, etc estan bien hechos, se adaptaran de forma natural a lo que tire encima.

ASI ES COMO SE PENSO EL MODELO RELACIONAL.

Este fue unos de los grandes aciertos cuando se creo. Porque ANTES de los rdbms, TODO ACCESO A DATOS ERA HECHO DENTRO DE LOS LENGUAJES y no se compartia ni logica de datos (malo) ni menos, datos (remalo).

Asi que:

Diseña tu BD de forma tal que puedas decir: "Como le invente una consulta a esto, funciona" y programas los triggers, procedimientos, etc que validen DATOS (que sea unico, que no este vacio, que sume , que reste), y deja lo concreto (formularios, reportes, etc) en Delphi.

[ingel]

Gracias Neftali por tu tiempo y tu respuesta. Te cuento un poco a que viene todo esto. Yo trabajo en un area de programacion de un Organismo Estatal que depende de otro Central con un Area de sistemas mucho mas grande. Nosotros por años desarrollamos en Delphi y tenemos varios sistemas en este lenguaje, tenemos cierta independencia (hasta ahora) pero el Area de Sistemas Central tiene convenio con Microsoft y promueve el uso de sus productos. A traves de los años ha llegado el momento en que nos hemos quedado sin soporte para Delphi y nos estamos viendo en la obligacion de migrar a .NET
La orden fue justamente esta , quitar todo el codigo posible del programa y pasarlo a la Base de Datos , para asi despues poder programar aplicaciones lo mas independiente y diferentes posibles Web , Mobiles , Escritorio contra la misma Base de datos.
Textualmente la orden fue "Quitar todos los SELECT , UPDATES , INSERT del codigo". No tenemos muchas opciones mas alla de preferir Delphi o .Net (el cual debemos empezar de cero, imagina el resto... )
sds

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

Empezado por ingel

Textualmente la orden fue "Quitar todos los SELECT , UPDATES , INSERT del codigo".

Hola ingel.
Te agradezco la explicación. Veo con ella que no es una decisión tuya, sino que viene de "otras instancias". En esos casos poco podemos hacer.

Lo que sigo sin entender es qué ventaja aporta cambiar (por poner un ejemplo para entender lo que quiero decir) en el código:

Código Delphi [-]
  UPDATE CLIENTES SET NOMBRE='kghkjhkjh'

Por una llamada a un SP que haga lo mismo:

Código Delphi [-]
  ActualizarNombreCliente('kghkjhkjh')

Contando que además en el segundo caso debes programar en la Base de Datos un SP que contenga esto:

Código Delphi [-]
  UPDATE CLIENTES SET NOMBRE='kghkjhkjh'

Tal vez no te estoy entendiendo, disculpa.
Tampoco quiero darle más vueltas al tema, puesto que ya has dicho que es algo que os han impuesto.

Un saludo.

[ingel]

En principio pensé que era por una cuestion de velocidad y supuce que tenian por estadisticas mejores rendimientos con mas codigo en la DB , yo como habras notado siempre programe con mucho codigo dentro de lenguaje porque estimaba , como tu dices, que no era
tan significativa esa diferencia... Tambien se me ocurrio que al querer darle diferentes opciones de aplicaciones al tener mas codigo en la base tendriamos que programar menos en las aplicaciones en caso de hacer web , escritorio , Celulares ... no te podria mencionar muchos motivos mas , pero tal vez lo desconozca... pero al venir de 'arriba' la orden , no me queda mas que acatar ...
Gracias por tus aclaraciones e interes sobre el tema, al menos me dejas tranquilo en que lo que yo pensaba no estaba tan errado