Paradox o MySQL

[MON___]

Para mis necesidades laborales trabajo desde hace años con tablas PARADOX. Poseo la correspondiente aplicación desarrollada en DELPHI (la primera versión la diseñé con ¡¡¡DELPHI 1!!!) para gestionar y acceder a mis datos. Trabajo en local e incluso mediante OBDC y PHP estoy diseñando algunas páginas WEB a modo de informe. El caso es que me tienen "mareado" algunos conocidos para que transfiera esas tablas PARADOX a MySQL (con la consiguiente modificación de la aplicación Delphi). Me hablan de las muchas ventajas y cualidades de MySQL, que no logro ver en algunas pruebas de las que he realizado.

¿Qué opináis?

[Neftali [Germán.Estévez]]

¿Exactamente qué necesidades requieres de la Base de Datos en tu aplicacion?
¿Multiusuario? ¿Cual es el volumen de trabajo?

EDITO: No lo había leído bien y ahora veo que trabajas en local.
No se cuales son las ventajas que tus amios te dan para que cambies.
Tal vez la versión embebded de Fb sea más adecuada para una aplicación local.

De todas maneras, aunque BDE+Paradox no es lo más eficiente, y está descontinuado, si tu aplicación trabaja bien y no necesita nada especial de un SGBD (a nivel de seguridad, SP, triggers, y cosas por el estilo), tal vez no sea mala idea seguir con una Base de Datos de escritorio.

[[poliburro]]

No hay duda, MySql. Por que?

La razón fundamental es que paradox y el BDE son tecnologias mantenidas por pura compatibilidad por parte de borland.

En cambio mysql sigue creciendo.

[karlaoax]

MySQL ya sea con componentes extras Zeos y MyDAC

[[poliburro]]

Empezado por karlaoax

MySQL ya sea con componentes extras Zeos y MyDAC

Yo era super fan de Zeos cuando programaba con Mysql, pero tanto zeos como MyDac me han decepcionado por el pobre soporte que ofrecen para ejecutar Procedimientos almacenados con Mysql, además de que el soporte para utilizar datsets sin conexión es nulo en ambos.

cuál es ahora mi solución preferida?, por supuesto ADO.

OJO, no digo que son malos, Tanto Zeos como mydac son perfectos cuando estás desarrollando aplicaciones con Sql embebido en tu aplicación. Pero cuando quieres desarrollar una verdadera aplicación Cliente Servidor. Pues, nop, en mi muy particular caso, no me convencen.

[Neftali [Germán.Estévez]]

Soy de los que piensa que una pregunta como:
¿Qué es mejor MySQL o Paradox?
Tiene una única respuesta válida:
¿Para qué?
El resto de contestaciones pueden ser válidas en muchos casos pero no en todos.

P.D: Soy consciente que que tal vez me van a caer palos por todos sitios, pero pienso que decir:
"MySQL es mejor que Paradox, por lo tanto hay que usar MySQL".
No siempre es verdad.

[MON___]

Gracias a todos por las respuestas. Como os dije trabajo en local . La razón por la que me recomiendan el paso a MySQL es porque había empezado a diseñar algunas páginas PHP con acceso a mis tablas Paradox a través de ODBC. Se me dijo que notaría una mejora en el rendimiento si las convirtiese en MySQL. Lo he hecho con algunas de ellas para probar el rendimiento y, sinceramente, no he notado una mejora considerable que justifique migrar a MySQL. Las pruebas las he realizado con una tabla principal (algo más de 2000 registros y 22 campos de diferentes tipos) y un par de tablas vinculadas a ella.

[juanelo]

Empezado por MON___

Gracias a todos por las respuestas. Como os dije trabajo en local . La razón por la que me recomiendan el paso a MySQL es porque había empezado a diseñar algunas páginas PHP con acceso a mis tablas Paradox a través de ODBC. Se me dijo que notaría una mejora en el rendimiento si las convirtiese en MySQL. Lo he hecho con algunas de ellas para probar el rendimiento y, sinceramente, no he notado una mejora considerable que justifique migrar a MySQL. Las pruebas las he realizado con una tabla principal (algo más de 2000 registros y 22 campos de diferentes tipos) y un par de tablas vinculadas a ella.

Hola que tal,
En mi experiencia con paradox NUNCA, PERO NUNCA montes un aplicacion web sobre paradox, no fue diseñada para eso, la verdad es que yo prefiero Firebird a cualquier base de datos open source, tiene un excelente rendimiento y es super facil de administrar (yo diria que hay cero administracion).
Saludos

[[egostar]]

Desde mi punto de vista, coincido con marcoszorrilla, la mejor base de datos y el mejor motor son siempre los que te permiten hacer lo que requieres.

Podemos hacer un debate sobre todo esto, pero siempre caeremos en las preferencias de cada quien, yo aún sigo utilizando Paradox para algunas aplicaciones que no requieren mas que eso, grabar, leer e imprimir datos.

Ahora ya entré a otro tipo de aplicaciones y por ese motivo comence a usar Firebird y me dió lo que necesitaba, ya probe la conectividad con ADO, con dbExpress, con Zeos y con Interbase (IBX) y sinceramente me quede con Interbase porque es lo que me hizo sentirme en mi zona de confort.

En fin, en tu caso si es necesario que cambies a otra base de datos por los motivos que ya te expresaron.

Salud OS

[Crashthebig]

creo que MySQL es mas potente y para conectarlo en red la mejor forma es mediante componentes ADO y MyODBC a travez de ODBC, paradox es un buena base de datos y aunque sea obsoleta aun la uso para mis aplicaciones monousuario ya que sus tablas son faciles de crear y para una aplicacion sencilla es mejor usar paradox porque para MySQl debes estar pendiente de si el servicio esta activo y todo eso.
aunque MySQL es mejor como todo lo bueno implica un poco mas de esfuerzo

[rolandoj]

Hola,

Quiero darte un consejo algo diferente.

En mi experiencia, el consejo más importante es que siempre trabajes con metodología de portabilidad de bases de datos; de esa forma, puedes cambiar de motor de Base de Datos sin recodificar tú aplicación y a largo plazo se ahorra un montón de tiempo y esfuerzo (te lo garantizo porque he trabajado con Oracle, Interbase, MSSQL Server, Paradox, entre otros y hacerlo con esa metodología me quito de encima todo tipo de problemas). En ese orden de ideas, cambiar de motor base de datos vale la pena en la medida en que el motor en sí te brinde alguna ventaja.

Ahora bien, estoy de acuerdo con que la primera pregunta antes de hacer un cambio es : Para qué ?

En tú caso, hay que preguntar, para que quieres la aplicación en Web ?. Si vá a ser accesada por un pequeño número de usuarios porque es muy propia de tú empresa o algo por el estilo, y sus consultas generan poco tráfico, probablemente no vale la pena el esfuerzo de cambiar, realmente no vas a ganar nada que lo justifique, de hecho probablemente pierdas ya que para este tipo de servicios a menudo un motor local puede ser más rápido. Si por el contrario, esperas un alto número de usuarios, entonces no hay discusión posible, indudablemente necesitas un motor basado en SQL; no solo por la velocidad, también por integridad de datos y el soporte a transacciones.