¿procedure?

[jachguate]

Un Stored Procedure, aun cuando sea invocado desde un cliente se ejecuta en el servidor, ahorrando tráfico de red, lo cual ya implica alguna ventaja. Además, es de esperar que el servidor sea una maquina mas rápida, mas memoria, con menos procesos en ejecución, etc. que cualquier terminal.

Hasta luego.

[Gydba]

Tengo entendido eso, pero es de esperar que exista alguna diferencia entre una SP creada/ejecutada desde código (digamosle dinámicamente) y otra ya existente en la BD. Es decir ¿Cómo es que el motor administra esto?

Te comentó que en Acce$$ las consultas definidas en la BD corren más rápido que creando las mismas consultas desde el código, puesto que se pre-compilan en el motor antes de ejecutarse, paso innecesario si la consulta se encuentra en la BD. Es decir que se ahorran un par de ms entre un método y otro.

Esto no sé si ayuda al hilo original pero es una interrogante que me generó el tema. Tengo que aclarar que no utilizo Interbase sino Firebird 1.5 rc8

[kinobi]

Empezado por Gydba

Tengo entendido eso, pero es de esperar que exista alguna diferencia entre una SP creada/ejecutada desde código (digamosle dinámicamente) y otra ya existente en la BD. Es decir ¿Cómo es que el motor administra esto?

En InterBase (y Firebird) los procedimientos almacenados se ejecutan (siempre) en el servidor. Estos, los procedimientos, se "precompilan" durante el almacenamiento (creación o modificación) a un código intermedio (denominado BLR - Binary Language Representation) que es el que ejecuta posteriormente el servidor cuando así se requiera.

Saludos.

[jachguate]

Solo aclararle al amigo Gydba que Un Stored Procedure es (como su nombre lo indica) un procedimiento que ya está almacenado en la base de datos. Algunos sistemas (como interbase) incluso almacenan una representación binaria del código (ya lo dijo Kinobi), evitando por completo re-pharsear cada vez que se ejecuta.

En algunos sistemas como oracle te permiten ejecutar un bloque pl/sql anónimo (que no es un SP). De cualquier forma, Oracle re-pharseará el código del SP cada vez que lo ejecutes, pues no almacena código binario de éste. Aún asi, como bien apuntabas, la diferencia entre ejecutar un Stored Procedure y un bloque anónimo no será sensible (a no ser que éste haga muy poco).

Hasta luego.

[Voutarks]

Ya se ha hablado varias veces por aqui sobre estos temas: cuando hay varias sedes remotas utilizando la misma base de datos.

Una solución que a mi me parece particularmente interesante para esto, aunque no la he utilizado todavía, es la replicación, mediante la cual en cada LAN o sede remota hay una copia de la base de datos y se van sincronizando; hay varias opciones segun haya un servidor central o no, replicacion simple o múltiple,....

Hay soluciones comerciales, como la que ofrece ibphoenix, libres aunque estancadas como fibre o bien esta, http://www.devarchive.com/f700.html, que me bajé yo pero que no he tenido tiempo de mirarlo bien. Es gratis para porpositos personales o educacionales, si se usa comercialmente habría que pagar 199 $

Otra posibilidad sería que uno mismo, mediante programación. implementase la replicación. Aqui tienes un hilo donde el compañero Cadetill explica la suya: http://www.clubdelphi.com/foros/show...ht=replicacion

[jachguate]

Con respecto de la opción de replicación mencionada por el amigo Voutarks, creo que siempre hay que evaluar. Si ya tenes una línea que te conecta las dos sucursales... yo creo que la replicación podría ser mas complicado que optimizar la aplicación (que siempre es posible).

Eso si... debes tener en cuenta que si hay un fallo en la línea de comunicación... la sucursal "cliente" se quedará fuera de línea, siendo imposible operar el sistema hasta que se restablezca la comunicación. Este es un punto en contra, pero si hay redundancia, o se confía en el proveedor... yo lo dejaría como está. Esto porque la replicación implica otra serie de factores que pueden provocar problemas con la información y tienden a ser mecanismos "de cristal", ya que es delicado aplicar cambios a la estructura, por no mencionar la cantidad de trabajo que puede significar diseñar/montar/mantener los mecanismos de replicación, y que tiene que haber usuarios responsables (¿existirán?) de correr los procesos de replicación o un mecanismo automátizado (que involucra otras cosas, como correo electrónico) que envie y actualice las bitácoras...

Decidirte entre un mecanismo u otro depende no de los factores ya comentados sino de algunos otros (regularmente subjetivos... )

Hasta luego.

[Voutarks]

jachguate, es cierto lo que comentas ya que la replicación conlleva todo eso. De acuerdo, es más costoso que intentar optimizar, pero es otra opción, y el resultado no es el mismo.

En el hilo que aporte anteriormente tambien se explica cómo intentar optimizar las conexiones.

Otra buena opción sería un desarrollo en tres capas aunque no se hasta que punto eso aceleraría las cosas.

[guillotmarc]

Hola.

Una valoración de las 3 alternativas propuestas, podría ser :

• Replicación entre Servidores :
  • Ventajas :
    • Es la solución más rápida, puesto que cualquier consulta se realiza a un Servidor en la red Local.
    • Si se cae la comunicación entre las dos ubicaciones, los usuarios pueden seguir trabajando perfectamente, puesto que solo necesitan acceder a un Servidor Local.
  • Inconvenientes :
    • Es costosa de programar.
    • Hay que tener en cuenta que pueden haber conflictos, de registros modificados a la vez en las dos ubicaciones, etc. ...
    • Hay que programar un sistema de recuperación de fallos, para el caso de que si un paquete de información se pierde, volverlo a enviar.
• Aplicación en 3 capas :
  • Ventajas :
    • Aumenta la velocidad puesto que es necesario transferir menos información a la estación cliente. Puesto que todos los cálculos y cruces de datos se realizan en el Servidor de Aplicaciones.
    • Al añadir una nueva capa, aumenta la modularidad de la aplicación, por lo que está mejor estructurada y es más sencilla de mantener. Esto es muy conveniente para grandes aplicaciones, donde las llamadas reglas de negocio pueden ser bastante complejas, implementandose todas ellas en la capa del Servidor de Aplicaciones.
  • Inconvenientes :
    • Es costosa de programar.

• Utilización masiva de Procedimientos Almacenados :
  • Ventajas :
    • Es la más sencilla de programar, y de implementar sobre una aplicación ya existente.
    • Aumenta la velocidad al pasar a ejecutarse gran parte de los cálculos (reglas de negocio) en el servidor de bases de datos. Por eso a veces se dice, que són aplicaciones de dos capas y media (a medio camino entre una aplicación de 3 capas, y una aplicación de 2 capas que solo tiene un aplicación cliente y un repositorio de datos).
  • Inconvenientes
    • Probablemente sea la opción que aumenta menos el rendimiento de las comunicaciones

Nota: Són unas valoraciones personales, invito a todo el mundo a añadir sus propias valoraciones a cada uno de los apartados, o a discutir algunas de las que he propuesto.

Saludos.

[Giniromero]

Hola,

Lo primero, muchas gracias a todospor todos vuestros comentarios, me están sirviendo de mucha ayuda.

Que es

un desarrollo en tres capas

?


Por qué crees que :

Probablemente sea la opción que aumenta menos el rendimiento de las comunicaciones

?

Por otro lado, entiendo, después de leer todo lo que se ha escrito en este foro, que la Replicación entre Servidores puede estar muy bien si realmente no es necesario que todos los puestos tengan acceso a todos los cambios producidos en las bases de datos, de un modo inmediato, lo cual es mi caso. ¿O me confundo?

En cualquier caso, entiendo que el uso de procedimientos, efectivamente, me reduciría el tráfico de la red, entre la oficina cliente y el servidor central, respecto a lo que tengo actualmente.

gracias, por todo, a todos.

Virginia

[jachguate]

Hola Vicky.

Empezado por Giniromero

En cualquier caso, entiendo que el uso de procedimientos, efectivamente, me reduciría el tráfico de la red, entre la oficina cliente y el servidor central, respecto a lo que tengo actualmente.

Esto depende.... si te llevas al cliente 1000 registros para realizar un cálculo, y esto lo metes a un SP... claro que te reduciría el tráfico de red. Por el contrario, si a través del SP siempre vas a hacer viajar los 1000 registros para mostrarlos en un DBGrid... no estas reduciendolo nada...

Ya habia mencionado en un mensaje anterior que debes acotar bien tus consultas, optimizandolas para minimizar el tráfico por la red. Es muy comun que trates de mostrar en una grilla todos los registros de los clientes, por ejemplo para que quien opera elija al cliente a quien atiende... pero es un desperdicio de la red. Si los tenes ordenados por apellido, y el cliente que se busca tiene apellido "Yoko", prácticamente viajarán todos los registros de clientes a la terminal... para elgir solamente uno! ...

Es mejor que preguntes el apellido (y quizas los nombres) al usuario, y hagas viajar solamente los registros que coincidan...

Nunca he usado IBX (que me parece que son los que usas), así que habrá que ver también cómo se comporta con los lookups y los filtros (si los usas), ya que suelen ser muy bonitos en la interfaz de usuario, pero regularmente generan un tráfico de red horrible...

En fin... espero haberte aclarado algo.

Saludos.