|
|
 |
 |
|
FTP | |
|
CCD | |
|
Buscar | |
|
Trucos | |
|
Trabajo | |
|
Foros | |
|
#1
19-02-2004
|
|||
|
|||
|
¿procedure?
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
__________________
Sonrie al mundo, y el mundo te sonreirá :) 
|
|
#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.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate
|
|
#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.
__________________
Suerte .: Gydba :.
|
|
#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. 
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate
|
|
#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
__________________
Suerte .: Gydba :.
|
|
#6
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
__________________
Emilio J. Curbelo
|
|
#7
19-02-2004
|
||||
|
||||
|
Cita:
Saludos.
|
|
#8
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.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de 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.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate
|
|
#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.
__________________
Emilio J. Curbelo
|
|
#11
19-02-2004
|
||||
|
||||
|
Hola.
Una valoración de las 3 alternativas propuestas, podría ser :
Saludos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no).
|
|
#12
20-02-2004
|
|||
|
|||
|
Hola,
Lo primero, muchas gracias a todospor todos vuestros comentarios, me están sirviendo de mucha ayuda. Que es Código:
un desarrollo en tres capas Por qué crees que : Código:
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
__________________
Sonrie al mundo, y el mundo te sonreirá :)
|
|
#13
20-02-2004
|
||||
|
||||
Hola Vicky.
Cita:
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.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate
|
|
#14
20-02-2004
|
||||
|
||||
|
Como comenta Juan Antonio, el uso de procedimientos almacenados solo te permitirá aumentar el rendimiento de algunos procesos.
Pongamos por ejemplo, el proceso de facturación. Supongamos que una vez al mes cogemos todos los Albaranes y generamos las Facturas correspondientes. La forma usual de hacerlo es mediante una consulta sobre los Albaranes, recorrer la consulta desde Delphi, e ir generando las Facturas una a una. En este caso está claro que por la red tienen que bajar todos los datos de los Albaranes, para poder recorrerlos en la aplicación, y después iran subiendo todas las Facturas una a una. Si utilizamos un procedmiento almacenado, la aplicación ejecuta el procedimiento, y como los procedimientos almacenados se ejecutan por el mismo motor de la base de datos, no hace falta que se envien de vuelta todos los Albaranes, sinó que todo se realiza sobre la memória del Servidor. En este caso lo único que viaja por la red es la instrucción de ejecutar el procedimiento y la notificación de que el el procedimiento ha finalizado. Como puedes adivinar, al no estar involucradas varias aplicaciones, ni haber ningún tráfico por la Red, es mucho más rápido el procedimiento de Facturación como procedimiento almacenado, que en la programación estándar dentro de la aplicación. En cambio en muchos casos el uso de un procedimiento almacenado, no mejora en nada o practicamente nada el rendimiento. Supongamos la inserción de un registro, tienen que viajar por la red los mismos datos (los datos a insertar) tanto si se ejecuta como una consulta (en un Query) como mediante un procedimiento almacenado. Aunque la ejecución en el Servidor de un procedimiento almacenado es más rápida que la de una consulta (puesto que esta segunda debe compilarla), este tiempo es despreciable comparado con el transporte de los datos. Por lo que la inserción tendrá practicamente el mismo rendimiento como consulta que como procedimiento almacenado. En las consultas ocurre le mismo, si queremos poner en una grid los 1000 clientes, practicamente tardará lo mismo obtenerlos mediante un Query que mediante un procedimiento almacenado. Puesto que el tiempo importante es el de transporte por la red, y este es exactamente igual en los dos casos. Así pues, como comenta Juan Antonio, hay que centrarse en el diseño de la aplicación para que requiera el menor tráfico posible. Por ejemplo, en lugar de bajar los 1000 registros, bajar solo los 25 primeros y si el usuario quier ver mas, le da a un botón y bajen los siguientes. O por ejemplo no utilizar consultas del tipo select * from Tabla, sinó que solo debemos consultar los campos que vamos a necesitar (los que ponemos en la grid), los otros no los necesitamos para nada, pero como los hemos puesto en la consulta, también se los bajará la aplicación, con lo que va a tardar bastante más en obtener los datos que necesitabamos. Por eso comentaba que esta opción es la que menos incrementa el rendimiento, puesto que en algunos procesos concretos puedes aumentar drasticamente la velocidad de ejecución del proceso, pero en la mayoría de casos, no obtienes practicamente ninguna mejora. Saludos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no).
|
|
#15
20-02-2004
|
||||
|
||||
|
Respecto a las aplicaciones de 3 capas, són aquellas en que las aplicaciones que utilizan los usuarios no se conectan directamente con la base de datos, sinó que pasan sus solicitudes a otra aplicación especial (a la que se suele llamar servidor de aplicaciones) que será la que se conectará a la base de datos, consultará los datos, los tratará si es necesario (hara los filtrados correspondientes, cruce de datos, cálculos, etc ....) y finalmente devolverá a la aplicación del usuario los datos solicitados, debidamente tratados para que no tenga que hacer ningún cálculo con ellos, solo mostrarlos.
De esta forma viajan menos datos por la red, ya que solo viajan los datos imprescindibles, en cambio los datos que solo se requieren para hacer cálculos, etc... pero que no están destinados a que los vea el usuario, no viajarán por la red, puesto que ya habrán sido tratados en el servidor de aplicaciones. Como puedes ver, de esta forma también se disminuye el volumen de datos que viajan por la Red. Además esta opción es mejor que la del uso de procedimientos almacenados, puesto que muchos cálculos no se pueden realizar dentro de un procedimiento almacenado, pero si que se pueden hacer en una aplicación Delphi (mezcla de datos de dos bases de datos distintas, ....). De esta forma, al hacerse más cálculos en el Servidor (las famosas reglas de negocio), se reduce la cantidad de datos que hay que enviar a la aplicación de usuario. Aunque como puedes adivinar, tiene el mismo problema que habiamos comentado con los procedimientos almacenados. Para hacer una inserción, tienen que viajar por la Red todos los datos a insertar, por lo que el rendimiento será parecido al de una consulta INSERT. Y si queremos cargar en una grid 1000 registros, el rendimiento también es el mismo puesto que tanto da bajar todos esos datos directamente de la base de datos, de un procedimiento almacenado, o de un servidor de aplicaciones. Por lo que otra vez tienes que estar pensando en diseñar una aplicación que reduzca la cantidad de información que se debe mover (de la misma forma que habiamos comentado antes, limitando la cantidad de registros que se envian, así como la cantidad de campos). Como puedes ver, en una aplicación sencillla practicamente no se obtiene ninguna mejora de utilizar procedimientos almacenados, o 3 capas. Pero cuento más complejas sean las reglas de negocio, mas ventajas obtendremos de aplicar estas técnicas. (Me refiero a casos, como que cada vez que se da de alta un producto, se debe crear automáticamente un registro de fecha y usuario de creación, un entrada de stock, ...) Saludos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). Última edición por guillotmarc fecha: 20-02-2004 a las 18:27:08.
|
|
#16
23-02-2004
|
|||
|
|||
|
Hola a todos,
Gracias por las aclaraciones. En mi aplicación, efectivamente he tenido en cuenta que cuantos menos registros tramite cada vez, mejor. De hecho, tengo una tabla principal, que tiene a todos mis cliente, y que me muestra sólo uno por vez, siendo el primero de la tabla, por defecto el que me muestra al abrirse el programa. Las demás tablas de mi aplicación me muestran sólo los registros que tienen que ver con ese usuario, lo cual, como puedes imajinar, es bastante más reducido que mostrar toda la tabla. Mi mayor problema viene cuando, alguno de esos clientes, tienen en información económica muchos registros de asientos económicos. Me lo muestra bien en el Grid, pero tengo un procedimiento que se encarda de filtrar, de todos esos apuntes de ese cliente, cuales están pendientes de pago, y esos me los muestra en un grid de un nuevo form, en el que sólo se muestran esos registros. Lo que me tarda es al abrir ese form, que por otro lado tiene campos calculados, tal como lo había montado, sin usar estos procedures de IB. Una de las cosas que le he programado en el procedure de IB es que directamente calcule esos campos calculados, lo cual, esperaba, al tramitarlo directamente el servidor, me implicase una mejora de rendimiento. De hecho, he descubierto, que en algunos momentos, estos campos calculados, (de este procedimiento de la aplicación oo de cualquier otro de los que he tenido que poner en ella), que en la red local donde está el servidor no dan problemas, en la oficina cliente, algunas veces, no muestran la información. Como si no pudiesen calcular el valor que en ellos tiene que ir. Pero si cierras el programa y lo vuelves a abrir, te los vuelve a mostrar bien, otro rato, hasta que se vuelve a "cansar" de calcularlos. Por cierto, me comentas que hay también posibilidad de pedirle a la aplicación que sólo me muestre X registros, en vez de todos los de la tabla, ¿esto como se hace en interbase? por que lo he estado mirando y me daban un código SQL que supuestamente sirbe para programar esto, pero no me ha funcionado. Muchas gracias por la ayuda, Saludos, Virginia
__________________
Sonrie al mundo, y el mundo te sonreirá :)
|
|
#17
23-02-2004
|
||||
|
||||
|
Hola Virgina.
Para mostrar n registros, puedes utilizar la cláusula ROWS. select NOMBRE, APELLIDOS from CLIENTES rows 25 Tiene bastantes posiblidades de utilización, por lo que lo deberías consultar en el manual. Respecto a los campos calculados, nunca he tenido ese problema (no utilizo IBX) así que no se que decirte. Finalmente, respecto a la grid con asientos pendientes, quizá podrías hacer una nueva consulta que te los devuelva, en lugar de filtrar los datos de otra consulta. Aunque eso implique un nuevo traspaso de datos con el servidor, puede mejorar el rendimiento de la aplicación (si el filtrado en IBX es tan lento como parece indicar este problema). Yo utilizo mucho los ClientDataset, quizá te interesaría también probarlos. Una vez cargados los datos en un ClientDataset, no hay ninguna comunicación posterior con el Servidor (ideal para conexiones lentas), excepto si se hacen modificaciones, que se pasarán todas de golpe al llamar al método ApplyUpdates. En los ClientDatasets nunca he tenido los problemas que has comentado con campos calculados y filtros. Saludos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no).
|
|
#18
24-02-2004
|
|||
|
|||
|
Gracias por lo de ROW. Yo estaba usando TOP... y claro... pos' no funcionaba.
Voy a echarle un vistazo a lo que me comentas. Garcias por todo. Virginia
__________________
Sonrie al mundo, y el mundo te sonreirá :)
|
|
#19
26-02-2004
|
||||
|
||||
|
No estoy muy claro si esto te puede ayudar pero de todos modos te lo dire.
Si estoy equibacado me disculpan no lo recuerdo bien. Segun lei si se pueden configurar los router con una direccion fija y un prefijo estos funcionarian como si encontraran en un red interna y creo que esto podria mejorar la velocidad.
|
 |
|
|
 |
|
Mode Lineal
