Necesito InterBase ???
 

Hola a todos

Les cuento mi problema.
Desarrollé una aplicación en Delphi 5 y base de datos Paradox 7. Son ocho computadoras, todas corren bajo Windows 98. Todos los datos están puestos en una de las computadoras (la que más veces debe acceder). La velocidad de acceso desde las terminales cada vez es más lenta. Tengo tablas de 3000 y 6000 registros mas o menos.
Les he preguntado a usuarios de InterBase y me han dicho que para una red domestica, como la que les describo, quizas no presice InterBase (o cliente/servidor), que hasta podria dejarlo igual o empeorar.
Si es necesario les puedo describir la complejidad de algunas consultas en otra oportunidad.

Me gustaría saber que opinan Uds. Y si opinan que debo cambiar por InterBase, sugieranme como inplementar el cambio.

Gracias desde ya.

Hola.

A mi me parece que firebird es la base de datos ideal para la carga de trabajo que propones. Es mucho mas estable/confiable que paradox. Con una máquina mas o menos potente haciendo de servidor y una red bien configurada, te podes evitar el hacer viajar todos los datos por la red en el caso de las consultas.

También es de esperar que el motor de base de datos genere planes mas óptimos para consultas complejas.

A esto añadiré la capacidad de obtener copias de seguridad aún con usuarios conectados a la base de datos y el hecho de poder tener transacciones con un nivel de aislamiento serializable, para consultas e informes largos.

Todo esto de cara mas a a la concurrencia y optimización. Con 6000 registros, ningún motor decente debiera tener problemas.

Hasta luego.

;)

Disculpame que haya demorado en responderte.

Entiendo lo de los 6000 registros porque noto que al intentar cargar por ej. 3 de los 6000 no tiene problemas. El problema está en consultas en las que debo leer del mismo registro más de una ves, y el resultado de la consulta podria estar compuesto de mas de 1000 registros. Lo mismo pasa con una consulta identica pero agrupada con el "Sum" de Sql.

Estas consultas tienen en algunos casos 6 o 7 "Left Outer" o "Inner Join". Ademas la repito con pequeñas variantes dentro de la misma consulta usando "Union" entre 8 y 10 veces. Esto hace que al usar la consulta desde una PC remota, si el resultado que se obtiene, es pequeño, tarda poco, si es grande tarda mucho y si es muy grande aparece un error "Insuficiente memoria", error que no aparece si uso esa consulta desde la maquina que tiene los datos.

Te pregunto. Al usar "Join", la tabla llamada se carga entera en ram o solo la parte que necesito? Esto sería un problema porque al consultar una tabla grande, ésta llama a otras tan grandes como ella.
Otro dato que te doy es que tengo consultas donde el comando "Sum" es usado más de 50 veces y en cada una de sus oportunidades usa 6 o 7 campos de diferentes tablas y algun que otro parámetro.

Desde ya te agradesco todo lo que me puedas comentar. Chau

parece una consulta bastante compleja... supongo que firebird podrá resolverla mejor que paradox... y sobre estas dos, oracle, que es el rey de la optimización. Pero antes de creer mis propias conclusiones, valdria la pena que hagas tus propias pruebas.

[quote=Ignacio]Esto hace que al usar la consulta desde una PC remota, si el resultado que se obtiene, es pequeño, tarda poco, si es grande tarda mucho y si es muy grande aparece un error "Insuficiente memoria", error que no aparece si uso esa consulta desde la maquina que tiene los datos.[/sql] esto puede ocurrir porque usando paradox, todos los datos han de viajar al cliente para hacer los joins. Al usar c/s (como firebird, interbase, oracle u otro) este proceso se hace en la memoria del servidor y viajan solamente los datos que devuelva el join.

Esto depende del servidor. En el caso de paradox... es una caja cerrada. En el caso de los motores relacionales serios, regularmente podes consultar el plan de ejecución e inferir en las decisiones del servidor mediante hints de optimización.

Claro que para que el servidor tome buenas decisiones y escoja la mejor ruta para hacer el/los joins, es necesario que declares indices que sean útiles para este propósito.

Una vez el join esté resuelto.. creo que cualquier servidor tardaría mas o menos lo mismo en resumir los datos para sum o cualquier otra función agregada.

Si algo faltaba para empujarme a cambiar por una base de datos Cliente/Servidor es que están pensando en la necesidad de que los datos sean consultables (y aveces modificables) por los clientes mediante una página web.

Creo que esto me obliga a investigar Oracle (ademas de otras cosas que todavia desconosco).
Te preguno . ¿Como qrees que serían los pasos a seguir para introducirme en Oracle? Digo en cuanto libros, licencias y otras cosas que deba saber.

Gracias.

Solo aclarar que esto también se puede hacer perfectamente con un manejador de archivos (tipo paradox o Acess, todo depende de lo instalable/manejable en el servidor).

He de decir en primer lugar que Oracle es un producto caro, además de medio complicado. Eso si, vale lo que cuesta y la complejidad tiene su premio: Buen desempeño y escalabilidad a cualquier nivel, incluyendo clusters y los nuevos "computational grids".

Si el presupuesto de tu proyecto es limitado, será mejor que penses en una opción como firebird, que no es tan escalable, pero si tiene muy buen rendimiento y muchas, muchas buenas prestaciones.

De cualqueir forma, para inciar con Oracle te recomiendo la lectura de los siguientes hilos (y los vínculos que hay alli):

Donde consigo un tutorial de Oracle
Primeros pasos en Oracle

Además, la busqueda de los foros te arrojará mas información.

Sobre las licencias, será mejor que contactes con tu representante local de Oracle (y que estes sentado :D)

Hasta luego.

;)

Wop!

Para completar un poco los comentarios del compañero jachguate, te quería comentar un tema en referencia a si ibas notar una mejora de rendimiento con firebird ( o cualquier otro motro de BD ) en comparación a sistemas de ficheros. Comentas que tienes consultas complejas con tablas relativamente grandes que te causan problemas. Bien, una de las ventajas de usar un servidor está en el proceso de ejecución de las consultas. Independientente del tema de la optimización, cuando ejecutas una consulta en Paradox, el PC cliente tiene que traerse todos lo datos de todas las tablas implicadas en modo local (con el increible tráfico de red que esto provoca). Una vez en local, es la propia máquina cliente la que se encarga de aplicar las joins y condiciones oportunas. En cambio, con un SGBD, es el servidor quien realiza la consulta, y solamente se entrega al cliente el conjunto de datos solicitado.
Me parece que la mejora es indiscutible, dejando a parte las posibilidades de triggers, procedimientos, etc.

Ah! otra cosa. Aunque tengas que trabajar basado en web, si la carga de usuarios no va acrecer increiblemente, con firebird tienes motor para años. Creo Oracle solamente es justificable en entornos con cargas muy, muy elevadas. :)

Bueno, de hecho leí algunas estadísticas una vez, que demostraban que interbase escalaba mucho mejor que mySQL y SQL Server.

De hecho, según el resultado de aquellos tests (no encontré la referencia, pero si interesa, me tomo mas tiempo para buscarla)... con el hardware adecuado podrias servir hasta 3 lineas T1 completitas con un Interbase 6.0 (que es la base de firebird).

Asi que, siempre que las consultas no sean demasiado complejas... yo diría que con firebird tenes para toda la vida. Me refiero, por supuesto, a escalabilidad en número de usuarios, no ocurre igual con el volumen de datos, donde Oracle sigue escalando mucho mejor.

Hasta luego.

;)

Totalmente de acuerdo, por eso dije que tenía de sobra con firebird a no ser que el volúmen creciese incriblemente ;)