PDA

Ver la Versión Completa : Qué motor DB me recomiendan?


MaMu
04-01-2008, 23:05:37
Qué motor DB me recomiendan para una aplicación de forma local?
Resulta que la habia realizado con access (mdb), pero se va ralentizando mucho. Que alternativas tengo? Me gusta mucho mySql, pero hacerlo correr para una aplicación local que no este en red, me parece exesivo. Hay algo que pueda usar?

Saludos

Caral
04-01-2008, 23:18:32
Hola
Que se pone lenta access??:confused:
Tengo una base de datos (access) con mas de 70000 KB, es mucha informacion casi 7 años.
Trabajo en red con 8 ordenadores, todos actualizan, cuando quieren.
Nunca se me ha puesto lenta, me envía la información en décimas de segundo.
He hecho la prueba con mysql, firebird y access y no notas la diferencia en tiempo de entrega de datos.
Para mi el problema esta en como se llama a la base de datos, si access en local se te pone lenta, olvidate de mysql o firebird, seran mas lentas ya que procesan la información diferente, estos son servidores, lo que quiere decir que te darán la información en partes.
Es mi humilde opinion.;):)
Saludos

FGarcia
04-01-2008, 23:18:34
Que te parece usar la embbeded de mySQL o la embedded de Firebird?

P.D. ¿En que tipo de aplicacion estas usando tu bd Access?

juanelo
04-01-2008, 23:39:33
Para mi el problema esta en como se llama a la base de datos, si access en local se te pone lenta, olvidate de mysql o firebird, seran mas lentas ya que procesan la información diferente, estos son servidores, lo que quiere decir que te darán la información en partes.
Es mi humilde opinion.;):)
Saludos

Que tal,
Pues discrepo en lo que dice Caral en su comentario acerca de Firebird, el hecho de que sea un servidor no implica el que de manera local se vuelva mas lenta, mas bien, el problema es muchas veces la cantidad de informacion que pretendemos traer hacia el usuario, y la forma poco optima en que se obtiene esta, por ejemplo una query mal hecha.

En lo que estoy de acuerdo es en el comentario de FGarcia, si la aplicacion solo va accesar a los datos desde la misma computadora, entonces existe la version embbeded de firebird.

PD: Tengo base de datos de mas de 500MB (tablas con mas de un millon de registros) corriendo de manera "local" aun con una instalacion de servidor en firebird, y la operacion cotidiana sigue teniendo la misma velocidad como el primer dia.

Saludos

Caral
05-01-2008, 00:35:37
Hola
Pues el caso de la rapidez o lentitud, esta muy discutido.
Ya lo comente y tu lo reafirmas Juanelo, depende de como se llame a las tablas, sea con tables o querys, pero aun asi, depende, siempre depende.
La tablas se pueden llamar con access, prácticamente igual que con otros, si colocas un top, este enviara los datos necesarios y aligerara el proceso.
Firebird es rápido, es cierto, pero access lo es también si se sabe usar:D.
Lo digo, tengo consultas en las que llama a cinco tablas a la vez y me envía una cantidad de datos grande y no hay diferencia (optica) usando firebird en la misma consulta.
Como siempre digo, esta bien, Firebird tiene los Tigers, bueno access tiene gatitos.:D:D
No digo que access sea bueno, o una buena opción, solo digo que no se le puede echar la culpa de la rapidez, lentitud, desorden, datos incompletos etc, etc, a access u otra, normalmente están mal hechas las consultas.
Saludos

MaMu
05-01-2008, 03:21:41
Sin embargo, si a la misma aplicacion que desarrolle, le cambio una simple base access, por un motor mySQL, la aplicacion vuela, es rapidisima. A lo que voy, es que no quiero usar access, quiero un verdadero motor, algo potente, porque hoy accedo de forma local, quizas en un futuro lo haga de forma remota. Como es el tema del mySQL embbeded, me interesa mucho, hay alguna nota de aplicacion etc etc. orientenme para saber por donde empezar a leer.

En cuanto a velocidad y performance, opino igual que Caral, y puede ser discutible a cualquier punto, ahora bien, no es mas que medir el tiempo que tarda el motor en entregar un cursor de datos a una pc cliente, y probar esto mismo con varios motores diferentes, en fin, no es mi objeto este tema, sino mas bien, avanzar un poquito mas a otra tecnologia mejor.

Saludos y gracias a todos.

Lepe
05-01-2008, 14:02:49
Como siempre digo, esta bien, Firebird tiene los Tigers, bueno access tiene gatitos.:D:D


Me ha gustado mucho esa afirmación, no la había escuchado nunca, (te la copio ;)).

La estrategia Embebida, quizás te haga tomar decisiones que después en red tengas que desechar. Por ejemplo, como es local (1 solo usuario) "¿para qué voy a usar Procedimientos almacenados?, si de todas formas el servidor y el cliente es el mismo ordenador...." al final acabas haciendo una aplicación de escritorio que al poner en red tendrá problemas.

Si de veras quieres embarcarte en Cliente/Servidor, yo lo hacía directamente para ese sistema, al tiempo de poner en red, solo tendrías que configurar la dirección de la base de datos.

Es cierto que la filosofía de desarrollo es totalmente distinto a tablas de escritorio, eres tú quien tiene que valorar si ese esfuerzo merece la pena.

Saludos

Caral
05-01-2008, 14:39:39
Hola
Pues si estas convencido en cambiar de base de datos, yo me inclinaria por firebird.
He probado (soy un curioso) Mysql y Firebird, me quedo con la segunda.
Sigo pensando en que quien sabe que programa tengas, en mis pruebas mysql con ado, fue mas lenta, mucho mas lenta que access, en local, en red, se durmio en los laureles, ya con zeos cambio.
Estan bien las opiniones, asi tendras un punto de vista mas amplio.
Recuerda, aqui el Novato soy yo, hazle caso a los que si saben.
Saludos

waly2k1
06-01-2008, 07:29:17
Desde ya si tienes la oportunidad de migrar tu aplicación a una base de datos real, hacelo. No te quedes jamás con Access, una cosa es un gestor de Base de Datos y otra cosa totalmente distinta es un archivo compartido en red con formato BD. Un 'archivo' Access a medida que crece pierde perfomance y ni hablar de muchos usuarios accediendo a ese archivo, con lo cual tu aplicación pasa de ser algo bueno, eficiente a un mal programita, tampoco hablo de los casos en que se corrompe el archivo y pierdes toda tu información.

Prueba con Interbase, Firebird o muchas otras opciones de Gestores de Bases de Datos que por ser local no van a ser mas lentos jamás que Access. Piensa siempre en 'grande', nunca se sabe el volumen de información que podrá llegar a manejar tu aplicación a futuro, ahora sí sabes lo que no debes usar.

Bueno, a pesar de ser redundante espero te sirva de algo mi consejo. Exitos!

MaMu
06-01-2008, 07:52:31
Ya estoy decidido, voy a migrar todo utilizando un gestor de DB, yo estuve usando mySQL y Zeos, una combinacion mas que satisfactoria, pero el tema es que no me queda claro como es el tema del mySql embebido, ya que lo que no quiero hacer, es tener que instalar el servidor mySql, hay alguna forma de resolver eso?, y lo digo tanto para mySql/Firebird, como si fuese un MDAC pero para mySql o Firebird.

Saludos

Casimiro Notevi
06-01-2008, 16:26:49
Yo usaría firebird, simplemente una dll y listo.

MaMu
08-01-2008, 01:15:00
Yo usaría firebird, simplemente una dll y listo.

Me gusta eso, y como seria? accediendo a las funciones de la dll para el manejo de la DB?, seria igual en caso de que usara mySQL?

Saludos

Chris
09-01-2008, 17:14:16
Bueno, auque parece que ya te estás decidiendo por una arquitectura de servidor empotrada, sólo a forma de sugerencia te recomendaría un motor que se llama TurboDB. (http://www.dataweb.de/en/products/delphi_database.html)
Es realmente bueno y rápido. Además de permitirte realizar búquedas de texto completo (si te interesan).

El único inconveniente es que es de pago, pero merece la pena que le pongas un ojo. Tienen una versión trial para descargar. Es muy fácil de utilizar.

jachguate
10-01-2008, 06:51:01
Podes entrarle a firebird con ADO, con IBX con BDE (obsoleto, pero funcional), con MDO, con IBO, FIBPlus y ¡orale! hay muchas opciones.

El hecho de la dll, es totalmente transparente para vos. Vos mirás siempre Datasets de delphi, queries, tablas, bases de datos, etc.

Con IBX/MDO/FIBPlus, que derivan de un viejo proyecto llamado FreeIB, tenés que manejar de manera explicita las transacciones, pero al final te acostumbrás.

Si usas el FirebirdEmbedded, podes desarrollar teniendo instaldo un FirebirdServer, y al final, cuando distribuis la aplicación, sustituis el dll del cliente de firebird por el dll del embedded y eso es todo!

Es muy práctico, y tiene toda la potencia de firebird, simplemente sorprendente!.

Con la característica de poder correr bases de datos de solo lectura (ver gfix -mode), podes hacer aplicaciones de acceso a base de datos (una enciclopedia, o un directorio telefónico nacional, por ejemplo) que se distribuyan sobre medios de solo lectura (cd-roms/dvd-roms).

No hablo mas... ya me salí del tema. :)

Hasta luego.

Oriol M.
10-01-2008, 19:35:42
Hola a todos, me sorprende un poco el hecho que no se haya mencionado PostgreSQL como opción para migrar la BD. Tengo algunos años de estar trabajando con esto, y hasta ahora todas las comparaciones que he realizado no me han convencido de cambiar.

Aunque la aplicación que se menciona trabaja de manera local, es mucho mejor tener el servidor de BD aparte por cuestiones de portabilidad y escalabilidad, a la hora de migrar a una arquitectura de cliente-servidor, el trabajo es sólo de seguridad para las conexiones.

Saludos.

jachguate
10-01-2008, 20:10:10
Hola a todos, me sorprende un poco el hecho que no se haya mencionado PostgreSQL como opción para migrar la BD.
Pues faltaba tu opinión, indudablemente ;)

Aunque la aplicación que se menciona trabaja de manera local, es mucho mejor tener el servidor de BD aparte por cuestiones de portabilidad y escalabilidad, a la hora de migrar a una arquitectura de cliente-servidor, el trabajo es sólo de seguridad para las conexiones.
Utilizando una solución como Firebird Embedded, esta afirmación tuya sobre la escalabilidad, carece de sentido.

Hasta luego.

;)

egostar
10-01-2008, 22:28:47
Utilizando una solución como Firebird Embedded, esta afirmación tuya sobre la escalabilidad, carece de sentido.


Veamos, yo no entiendo algo, que es FB Embedded, hay diferentes versiones de FB :confused:

Yo estoy trabajando con FB 2.0, como se si es embedded o no :confused:

Salud OS

jachguate
10-01-2008, 22:49:11
Veamos, yo no entiendo algo, que es FB Embedded, hay diferentes versiones de FB :confused:
Yo diría que hay diferentes "ediciones", pues hasta ahora, cada "versión" ha tenido una "edición" embedded.

Yo estoy trabajando con FB 2.0, como se si es embedded o no :confused:

Si no lo sabes, puedo asegurarte categóricamente que no lo es. :D:D:D

El chiste del "embedded" es que podes ejecutar una aplicación sin la necesidad de instalar el motor, lo que resulta muy conveniente en muchos casos.

Por ejemplo, en mi usb tengo cierta aplicación, que ejecuto en cualquier equipo, con toda una base de datos y la funcionalidad que he querido.

Una limitante es que es monousuario, dado que el motor se ejecuta desde dentro de tu aplicación (está incrustado en ella), y la otra, es que el motor acepta la conexión independientemente del usuario/clave que se le de, pues no hay base de datos de seguridad para comprobar. Puede vivirse con ambas, aunque supongo que la segunda cambiará en cuanto salga la versión 3, que según recuerdo, ya tendrá la seguridad dentro de la propia base de datos.

Hasta luego.

;)

egostar
10-01-2008, 23:05:45
Yo diría que hay diferentes "ediciones", pues hasta ahora, cada "versión" ha tenido una "edición" embedded.

Si no lo sabes, puedo asegurarte categóricamente que no lo es. :D:D:D

El chiste del "embedded" es que podes ejecutar una aplicación sin la necesidad de instalar el motor, lo que resulta muy conveniente en muchos casos.

Por ejemplo, en mi usb tengo cierta aplicación, que ejecuto en cualquier equipo, con toda una base de datos y la funcionalidad que he querido.

Una limitante es que es monousuario, dado que el motor se ejecuta desde dentro de tu aplicación (está incrustado en ella), y la otra, es que el motor acepta la conexión independientemente del usuario/clave que se le de, pues no hay base de datos de seguridad para comprobar. Puede vivirse con ambas, aunque supongo que la segunda cambiará en cuanto salga la versión 3, que según recuerdo, ya tendrá la seguridad dentro de la propia base de datos.

Hasta luego.

;)

Perdon es que soy novato. te debo una :)

Salud OS

PD, ya pues, no me regañes :D:D:D

jachguate
10-01-2008, 23:14:00
Perdon es que soy novato.
:eek::eek::eek:
ya pues, no me regañes
:eek::eek::eek:

:rolleyes::rolleyes::rolleyes:
:cool:

courtois
11-01-2008, 02:51:21
Si la aplicacion es local y esta lenta con access, lo mejor seria averiguar por que esta lenta, y si se descubre que se debe realmente al motor de bases de datos entonces pensar en cambiarlo. ¿Para que trabajar de balde en una migracion si resulta luego que no es eso?

lejia
11-01-2008, 15:57:59
Lo mejor, siempre lo tendrás echo, es hacer una aplicacion independiente de la base de datos que use. Solo depuses es hacer una aplicacion que te cambie de una base de datos a otra.
El tema de si local o no. Es facil, si la haces en red, tendrás que controlar mas cosas,, pero al final es mas rentable. Te digo, y comento, si no voy a meter muchos datos,, mejor una base de datos local, si vas a meter muchos datos, mejor con servidor. El porque es bastante sencillo, las busquedas en motores, es mas lento que directamente sobre ficheros, siempre que la informacion que tengamos sea de pocos registros. Cuando es mayor, la busqueda en una que tenga motor, es mas rapido, digamos que va al grano.
Las bases de datos de servidor, estan desarrolladas, en unos arboles llamados, avl, Es rapido, cuando tienes mucha informacion, pero ucando hay poca, la busqueda en un fichero es mas rapido. De todas maneras, con servidor es mejor.. Siempre podras tener mas informacion, y podrás conectar varios ordenadores. Solo tendrás que controlar el acceso a el, nada mas.

MaMu
30-01-2008, 19:03:09
En primer lugar, gracias a todos por las recomendaciones y por compartir sus experiencias con los diversos motores.
Yo particularmente me encuentro desarrollando aplicaciones utilizando mySql en Delphi 7, bajo el dominio de los componentes Zeos, de los cuales estoy más que conforme.
Si bien mi idea era no tener que instalar un mySql server, ya que es un tarea que requiere al menos un mínimo de conocimiento por parte del usuario final de lo que se esta instalando y como debe ser configurado, he notado que por lo visto, un motor embebido en nuestra aplicación, es solo monousuario, lo que me traslada nuevamente al punto de partida en donde me encuentro.
La unica salvedad que se me ocurre, es recrear una instalación silenciosa del servidor mySql, en el momento de la instalación de mi aplicación, pasándole todos los parámetros y argumentos de la instalación y la creación de usuarios, etc..

gatosoft
30-01-2008, 21:39:54
bueno, yo estoy de acuerdo con Oriol... hacia falta PostgreSQL, trabajado con los Zeos creo que no tienen problema...

El isntalador lo cargo siempre en mi USB y con solo seguir los pasos (NEXT, NEXT, NEXT) ya lo tengo instalado.

Lo utilizo siempre como BD de escritorio, pero he hecho desarrollos hasta con 60 usuarios grabando operaciones diarias y con mas de 3'000.000 de registros en un año en la tabla con mas movimientos y no he tenido mayores dificultades...

La recomiendo 100%

Saludos,