¿procedure?

Giniromero · #1 19-02-2004

Hola a todos,

he terminado una aplicación en delphi 6 con interbase 7.

Tengo dos oficinas donde tienen que usar este programa, y que comparten la misma base de datos. Estas están conectadas entre si por una linea dedicada de 128. (se que hoy por hoy esto es muy poco amcho de banda, pero sobre eso yo no puedo hacer nada)

El problema es que en la oficina donde se encuantra el servidor con la base de datos, funciona rápido el programa, (puede tardar unos 2 seg. en tramitar el procedimiento), pero en la otra oficina es insufrible lo que tardan algunos procedimientos (esos mismos procedimientos puedentardar del orden de 30 seg.).

En el programa lo he implementado usando TIBDataSet, pero no he usando ningún procedure en la propia base de datos interbase.

He generado uno de los procedimientos que me dan problemas en un procedure en el propio IB, para evitarle calcular campos por código directamente desde el programa. pero no se si hay algún metodo mejor que me podais recomendar, o si realmente esto puede reducir tiempos.

Gracias,

Virginia

jachguate · #2 19-02-2004

Cuando un programa va a ejecutarse remotamente, tenes que tener MUY en cuenta el tráfico de red generado por el mismo, y optimizarlo evitando transferir datos que no son imprescindibles en el cliente. Además, con Interbase (como con la mayoría de las bases de datos serias) podes trasladar una buena parte del proceso al servidor, aprovechando triggers y stored procedures).

Debes acotar bien todos los datasets que abras en el cliente para que solo lo necesario viaje por la red.

Gydba · #3 19-02-2004

Me parece que debería tener mejor rendimiento si la SP se encuentra en el servidor y no ejecutada desde la app. cliente.

La opinión de jachguate también es importante.

Otro punto a ver quizás sea el diseño de la red y los recursos con los que cuenta el servidor.

jachguate · #4 19-02-2004

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 · #5 19-02-2004

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 · #6 19-02-2004

Cita:

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 · #7 19-02-2004

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 · #8 19-02-2004

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 · #9 19-02-2004

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 · #10 19-02-2004

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.