Acceso a datos (reflexion)

[charly]

Hola a tod@s.

El marco de trabajo es : Delphi 7 + Firebird + FIPlus.

En la actualidad tengo una aplicación en fase de explotación (versión 1) que soporta 30 usuarios en una red local sin ningún problema. Ademas tengo 4 conexiones por ADSL, y es aqui donde no consiguo afinar el tema. Asi que mis preguntas son:

- Se oye hablar de los componentes dbware, yo los uso y si no ,que tendría que hacer, insertar controles no-dbware y "cargarlos", trabajar con ellos y despues volcarlos con un insert o update? Si es asi el rendimiento es mejor?

- Hay miembros del club que aconsenjan trabajar estilo cajero de banco, yo creo que lo he implementado así, pero que marco de trabajo usan?

- En mis conexiones ADSL al insertar un registro de facturas por ejemplo, al pulsar el boton insert como no tengo abierta la conexion con la tabla, sigo los pasos de crear una sentecia SQL que no me devuelva ningun registro, para poder hacer un insert, es lo correcto ? y asi como lo hago hay un lapsus de 5 segundos hasta que se puede escribir en el control dbware.

- Sobre la velocidad de acceso a los datos, se que hay miembros del club que han echo comparativas de velocidad, podrian dar resultados para, si es necesario, cambiar de componentes de acceso a firebird (no importa que sean de pago).

El tema es que tengo que desarrollar la versión 2 de mi proyecto y esta debe ser la leche de rápida. Voy ha crear la DB de nueva (tomando lo ya echo) ya que durante 6 meses en fase de explotación del proyecto he tenido que implementar muchas cosas que se encontraban en la planificación original y seguro que por hay ahi mucho que optimizar. Asi que si tengo que cambiar los componentes o mi chip cerebral, quiero hacer antes de empezar. Incluso pense el crear paginas PHP para la introducion de pedidos, etc. pero creo que mis usuarios no estarian agusto sin sus DBGRib de busqueda, etc.

Un saludo a todos y gracias por su ayuda.

[guillotmarc]

Hola.

Nunca he hecho una aplicación similar, aunque en tu caso probaría con los componentes dbExpress, puesto que su forma de trabajo es el comentado de cajero de banco.

Es decir cuando abres un dataset, lo que se hace es lanzar un query, recoger todos los registros y guardarlos en memória local, cerrando posteriormente el query (es decir, que en el servidor no queda nada abierto).

A medida que haces modificacions, todo se va haciendo en la memória local, sin ningún acceso a la base de datos. Hasta el momento en que llamas al método ApplyUpdates, el cual pasa todos los cambios de golpe a la base de datos (mediante las sentencias INSERT y UPDATE necesarias)

Si aún así el rendimiento no te parece satisfactorio (Para añadir registros, tendrás que abrir antes un dataset vacío, cosa que lanzará un query a la base de datos, y que puede tardar en devolverlo). Siempre te queda la opción de trabajar como comentas, sin controles db-aware. Sin ninguna duda va a ser mucho más rápido. Sobre todo en el momento de añadir, porqué el usuario puede empezar a escribir los datos sin tener que esperar a que el servidor haya devuelto un dataset vacío.

Naturalmente esta opción conlleva mucho más código y por tanto horas de programación, por lo que solo te la recomiendo si no puedes conseguir una buena velocidad con los controles db-aware.

Saludos.

[pedrohdez]

Hola Charly,

Despues de algunas pruebas, mis clientes han optado por consolas remotas, bien con windows o con citrix, suele ser mas efectivo que andar recortando las prestaciones del programa para que se mueva correctamente a traves una conexion lenta.

Otro asunto es que solamente quieras servir al exterior una entrada de pedidos, en ese caso probablemente te sea mas comodo usar PHP o similar, y asi te evitas tener que instalar FB/IB a todos tus posibles usuarios y algo mas peliagudo, dar la clave de tu servidor.

En cuanto a la solución de guillormat, le veo una pega, cuando andas dando de alta facturas o pedidos necesitas leer mucha información auxiliar, codigos de articulos, clientes, comprobar saldos, stock, formas de pago etc. asi que el problema no es tanto la ficha en si, si no, todo el trafico que se mueve alrededor.

saludos,
Pedro.

[charly]

Gracias por vuestras respuestas (y sigo abierto a más)

Voy ha probar lo dicho por guillotmarc, creando una ventana y un dataset independientes y tomaré tiempos, ya os daré a todos los resultados.

Respecto a lo dicho por pedrohdez, me gustaría me dieras un poco más de información ya que aunque me imagino de que va el tema, no lo conozco.
En lo del trafico de red, por las tablas auxiliares que se ven involucradas la entrada de un pedido, te doy la razón, aunque he pensado no realizar ninguna comprobación desde delphi y dejarlo para los disparadores de la tabla. Pero ya sabemos que los usuarios a veces son muy perros y tener que poner el cursor sobre el campo que tiene el error es un esfuerzo que disminuye enormente su productividad.

Un saludo.
Charly

[pedrohdez]

Hola Charly

No es solo que dejes las comprobaciones para el servidor de BDs, es que el usuario quiere buscar el numero de cliente o cuando pone un cliente quiere que se vea su forma de pago y le haga el calculo de los vencimientos previstos o que muestre su estado de credito, o cuando pone un articulo quiere ver la descripción del mismo y su precio en la tarifa del cliente .... montones de datos que estan subiendo y bajando por la linea cada vez que cambia de dbEdit, vamos, que en mi opinion el echo de que uses dbawares o no no influye tanto en el resultado final.

[charly]

Y respecto al tema de las consolas. me puedes comentar algo?

[guillotmarc]

Hola.

Otra posible solución : Replicación de Datos.

Pones un Firebird en cada uno de los clientes, de forma que hacen todas las altas y modificaciones en el servidor local, y cuando deseas pasar los cambios, haces la conexión a Internet y pasas solo los datos que han cambiado al Servidor.

Si no te gusta instalar un servidor Interbase/Firebird, puedes usar el servidor embeeded (¿ como se traducirá esto ? ¿ integrado ?) de la versión 1.5 de Firebird.

Es una unica dll, si hasta ahora tenias que distribuir la gds32.dll, con la versión integrada solo tienes que distribuir la fbembedl.dll (normalmente se renombra a gds32.dll para que los programas no noten el cambio).

http://prdownloads.sourceforge.net/firebird/Firebird-1.5.0.3253_RC1_embed_win32.zip

Si quieres más documentación sobre como realizar la replicación (es decir como detectar cuales són los datos que han cambiado desde la ultima replicación), puedes consultar este artículo (aunque como tu caso es bastante sencillo, seguro que lo puedes simplificar bastante) :

http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_howto10

Es una solución que se aleja bastante de lo habitual, pero creo que te permitirá un sistema de introducción / modificación de datos rapidisimo de cara al usuario final.

Saludos.

[guillotmarc]

Hola.

Posteado originalmente por pedrohdez
En cuanto a la solución de guillormat, le veo una pega, cuando andas dando de alta facturas o pedidos necesitas leer mucha información auxiliar, codigos de articulos, clientes, comprobar saldos, stock, formas de pago etc. asi que el problema no es tanto la ficha en si, si no, todo el trafico que se mueve alrededor.


Completamente de acuerdo, pero la forma habitual de trabajar en dbExpress es con clientdatasets, la idea es abrir los clientdatasets con todos estos datos auxiliares al arrancar la aplicación, y a partir de ese momento cualquier acceso a esos datos solo implicará un acceso a la memória local. Naturalmente esto implica que al cargar la aplicación tardará un poco porqué se debe bajar esos datos, pero después la ejecución normal debe ser rápida.

El tema de los Servidores de Terminales (Cytrix, Terminal Server, ...), está muy bien, pero no me gusta tener que cargar al cliente con el coste de la licencia, que es bastante elevada, por eso intento utilizarla lo menos posible.

Saludos.