Hay beneficio en migrar BDE a DBExpress bajo esta metodolgía ?

[rolandoj]

Hola,

Estoy empezando a trabajar en migrar código basado en BDE a dbExpress. Ahora bien, el control transaccional que tengo en mi código original es 100% manual; o sea, todas las llamadas que se hacen son SQL puro. Para ser claro, lo que quiero decir es que todos los datos son capturados y desplegados sin utilizar controles como TDBEdit o similares, que estén asociados a algún TDataSet; por tanto, al momento de grabar se usan llamadas directas a SQL vía TQuery.

Por ejemplo, una rutina típica de grabación de un registro luce algo así como :



Procedure TdmSSWTablas.InsertarEnTablaHjMun(ADpto,AMncp,ACode,AName:String);
Begin
With SQLIngresar Do Begin
Try
Params[0].AsString:= ADpto;
Params[1].AsString:= AMncp;
Params[2].AsString:= ACode;
Params[3].AsString:= AName;
ExecSQL;
Except
On E:Exception Do Begin
raise Exception.CreateFmt(ESIE073,[ACode,AName,E.Message]);
End;
End;
End;
End;


Y por tanto, un control transaccional luce algo así como

begin
try
dmSistema.dbSistema.StartTransaction;
InsertarEnTablaHjMun('08','001','0017',AName);
.....
...
.
dmSistema.dbSistema.Commit;
Except
On E:Exception Do Begin
dmSistema.ProcesarErrorTransaccional(E.Message);
End;
end;
end;


Esta metodología la aplicó, entre otras cosas, para obtener portabilidad entre motores de Bases de Datos, y me ha dado excelentes resultados por lo que no planeo cambiarla.

La pregunta es : En este escenario, hay algún beneficio real en migrar a dbExpress ?. En especial, realmente se obtendrá una mejora significativa en velocidad ?

Si les extraña que pregunte cuando ya estoy migrando es porque las razones de la migración tienen un origen diferente.

[mamcx]

Bueno, BDE ya es una tecnologia "obsoleta" y dbExpress por el contraria se nota que ha recibido trabajo por parte de codegear....

[rolandoj]

Hola,

Gracias por la observación; pero que BDE sea "obsoleta" no implica que dbExpress sea necesariamente mejor en todo. La pregunta es porque los argumentos que he leído al respecto parten de un escenario en que la metodología usada con BDE es muy diferente a la que yo empleo y de hecho el principal argumento indica superioridad del dbExpress por usar, en el fondo, "exactamente" la misma metodología que ya yo uso con BDE para producir transacciones cortas. Como yo de por sí estoy usando transacciones cortas, ese principal argumento pierde validez, así que lo trato de averiguar es si hay otros aspectos que pudieran dar ventajas de rendimiento, ya que en cuanto a facilidades yo más bien he encontrado desventajas.

Bueno, BDE ya es una tecnologia "obsoleta" y dbExpress por el contraria se nota que ha recibido trabajo por parte de codegear....

[Nasca]

Lo mismo me equivoco pero me parece que tu metodología de trabajo no escala adecuadamente cuando se incrementa el número de tablas o la complejidad de sus relaciones. Imagina una tabla que tiene un detalle que a su ver maneja otros sub-detalles, programar eso de forma manual puede ser un pequeño infierno, sin embargo con DBX es todo automático.
No discuto que no se pueda hacer, pero me parece que a un coste altísimo.

Si te preocupa la portabilidad y eres cuidadoso con el SQL usado en tus datos, consultas, funciones y procedimientos almacenados no creo que te resulte muy complicado conseguirla con DBX.

[rolandoj]

Hola,

Gracias por la opinión.

Pués sí, te equivocas en eso de escalar. Si hay un esfuerzo algo mayor; pero no es significativo. Yo trabajo casi siempre con tablas grandes y relaciones bastante complejas donde usualmente grabamos documentos formados por varias tablas detalles, incluso a más de un nivel de detalle.

Por otra parte, esa metodología, basada en trabajar toda la edición separada del acceso a base de datos también permite migrar facilmente del modelo de cliente servidor convencional al modelo Web, permitiendo incluso que cliente y servidor esten sobre lenguajes distintos y también permite migrar con relativa facilidad entre herramientas de impresión. En general, si bien el esfuerzo inicial es mayor, a largo plazo es mucho más versatil y los beneficios son enormes.

En eso yo he hecho el "curso completo", ya que trabajé inicialmente con metodologías amarradas a la herramienta del momento; o sea usar controles relacionados a TDataSet y modelos similares; pero por amplia experiencia ya aprendí que a largo plazo es mucho mejor la metodología que uso hoy en día, a menos que se tengan razones para pensar que el programa que se esta desarrollando no sufriras cambios de plataforma.

Obviamente, vale aclarar, que con el tiempo he desarrollado rutinas y metodologías auxiliares que me simplifican mucho el uso de esta metodología. Ten en cuenta que lo que muestro en el ejemplo ya son las rutinas finales.

Lo que dices de la portabilidad del dbX, aún no lo conozco bien porque estoy empezando con él; pero tengo mis dudas, por dos razones:

1. Según entiendo, el usuario final no puede cambiar facilmente de motor de Base de Datos. Tendría que desarrollar uno una especie de BDE Administrator para brindar eso. Eso me es clave porque mis programas usualmente los desarrollos para aplicar a clientes distintos y no puedo amarrarlos a usar una sola Base de Datos.

2. Según creo, la conexión a Base de Datos pasa por el esquema del TClientDataSet; así que no podrían implementarse características de independencia como las que mencioné antes. En otras palabras, si se quiere tener las ventajas que tengo ahora con mi metodología, tocaría trabajar exactamente con dbExpress usando la misma filosofía que tengo actualmente con BDE, en consecuencia, solo podríamos hablar de ventajas de rendimiento; así que la pregunta sigue siendo : Hay razones para creer que dbX pueda brindar significativamente mejor rendimiento que BDE bajo este esquema de trabajo ?

Lo mismo me equivoco pero me parece que tu metodología de trabajo no escala adecuadamente cuando se incrementa el número de tablas o la complejidad de sus relaciones. Imagina una tabla que tiene un detalle que a su ver maneja otros sub-detalles, programar eso de forma manual puede ser un pequeño infierno, sin embargo con DBX es todo automático.
No discuto que no se pueda hacer, pero me parece que a un coste altísimo.

Si te preocupa la portabilidad y eres cuidadoso con el SQL usado en tus datos, consultas, funciones y procedimientos almacenados no creo que te resulte muy complicado conseguirla con DBX.

[basti]

[
1. Según entiendo, el usuario final no puede cambiar facilmente de motor de Base de Datos. Tendría que desarrollar uno una especie de BDE Administrator para brindar eso. Eso me es clave porque mis programas usualmente los desarrollos para aplicar a clientes distintos y no puedo amarrarlos a usar una sola Base de Datos.


Creo que todo lo contrario. El BDE tiene acceso a una serie de bases de datos, pero, al no estar en desarrollo, no permite el acceso a ninguna base de datos más ni a posibles versiones nuevas. Por otro lado, para dbExpress siguen actualizándose las librerías para nuevas versiones y nuevas bases de datos, además de las librerías de terceros que existen.

El cambio de una base de datos a otra (si utilizas un sql más o menos estándar), es tan simple como cambiar el driver en el/los SQLConnection.


2. Según creo, la conexión a Base de Datos pasa por el esquema del TClientDataSet; así que no podrían implementarse características de independencia como las que mencioné antes. En otras palabras, si se quiere tener las ventajas que tengo ahora con mi metodología, tocaría trabajar exactamente con dbExpress usando la misma filosofía que tengo actualmente con BDE, en consecuencia, solo podríamos hablar de ventajas de rendimiento; así que la pregunta sigue siendo : Hay razones para creer que dbX pueda brindar significativamente mejor rendimiento que BDE bajo este esquema de trabajo ?


En cuanto al rendimiento, más de lo mismo, al no estar soportado el BDE, no habrá mejor rendimiento que el que puedas tener ahora, cosa que sí puede pasar con dbExpress.

[pepon386]

Hola,

2. Según creo, la conexión a Base de Datos pasa por el esquema del TClientDataSet; así que no podrían implementarse características de independencia como las que mencioné antes. En otras palabras, si se quiere tener las ventajas que tengo ahora con mi metodología, tocaría trabajar exactamente con dbExpress usando la misma filosofía que tengo actualmente con BDE, en consecuencia, solo podríamos hablar de ventajas de rendimiento; así que la pregunta sigue siendo : Hay razones para creer que dbX pueda brindar significativamente mejor rendimiento que BDE bajo este esquema de trabajo ?


Siento discrepar contigo, pero precisamente la "gracia" del TClientDataSet es que te permite trabajar de la misma manera independientemente de la base de datos que haya detrás. Fíjate, incluso podrías seguir con la filosofía que tienes de hacer por SQL directo (como tú dices) las actualizaciones manteniendo el desarrollo visual y los componentes enlazados a datos, que a fin de cuentas es lo que te permite ahorrarte un montón de tiempo en el desarrollo.

[Nasca]

Creo que si trabajas con servidores SQL (como es tu caso) te evitarás alguna capa intermedia. El drivers dbx funciona como un conector intermedio entre la aplicación y la librería de acceso al servidor SQL, la conexión es casi directa. Y precisamente tiene ese diseño para facilitar la portabilidad entre distintos SGBD. Nunca he utilizado BDE pero me parece que incluye una capa más (algo anticuada y sin desarrollo), el propio BDE. En comparación Dbx es mas liviano y directo y en consecuencia mas rápido y eficiente, o eso creo yo.

Lo suyo sería montar un pequeño programa test dual (DBX y BDE) y probar el rendimiento con inserciones, select y modificaciones masivas.

De todas formas sigo pensando que el problema para portar aplicaciones entre distintos SGBD sigue estando en el subconjunto de datos, SQL y "programación" en el servidor que contemple la aplicación. Respetando eso no habría problema de intercambiar algunos parámetros en el SQLConection y listo. Cosa distinta sería aprovechar la misma base para interfaces web.

[rolandoj]

Hola,

Te cuento que efectivamente como parte de mi metodología mi uso de SQL es muy standard, y de hecho esa es parte fundamental de la portabilidad. En la práctica desde que uso mi metodología, cambiar de Base de Datos ha sido simplemente entrar al BDE y cambiar el Alias, sin que se cambie una sola línea de código.

Ahora bien, por lo mismo, y dado que BDE soporta ODBC, nunca he tenido problemas con las versiones más nuevas de motores de Bases de Datos; aún con drivers BDE hechos casí 10 años atras, la regla del primer parrafo se ha cumplido. Cuando me falló fué antes de usar la metodología y precisamente por estar empleando caracteristicas del motor que no eran standard. Pienso que los problemas podrían presentarse si hay cambios a nivel de ODBC; pero no creo que sea algo que esté próximo a ocurrir.

Lo que si me gustaría es que me comentaran como puede hacerse eso mismo en dbExpress. Claramente estoy hablando, "sin cambiar ejecutables"; porque hasta ahora, según lo que he leído, es necesario hacerlo, o desarrollar nuestro propio BDE Administrator. Si hay forma de trabajar igual que con el BDE, me gustaría que me lo detallaran o me dijeran donde encuentro como hacerlo.

En cuanto a lo del rendimiento, difiero de tú opinión. No creo que el solo hecho de no tener nuevos desarrollos para BDE garantice que dbExpress tenga un rendimiento mejor. En 25 años que tengo dedicado a desarrollo de software ha sido más o menos frecuente el hecho de que nuevos productos presenten rendimientos inferiores a los productos existentes. Por supuesto, quiero ser claro en que no tengo base para saber como es en ese sentido dbExpress frente a BDE; precisamente es en lo que trato de documentarme en este hilo

[

Creo que todo lo contrario. El BDE tiene acceso a una serie de bases de datos, pero, al no estar en desarrollo, no permite el acceso a ninguna base de datos más ni a posibles versiones nuevas. Por otro lado, para dbExpress siguen actualizándose las librerías para nuevas versiones y nuevas bases de datos, además de las librerías de terceros que existen.

El cambio de una base de datos a otra (si utilizas un sql más o menos estándar), es tan simple como cambiar el driver en el/los SQLConnection.




En cuanto al rendimiento, más de lo mismo, al no estar soportado el BDE, no habrá mejor rendimiento que el que puedas tener ahora, cosa que sí puede pasar con dbExpress.

[rolandoj]

Hola,

Gracias por tús comentarios.

Creo que tocas tres puntos importantes.

El primero es como envía BDE y como envía dbExpress. Pienso que es el punto más importante para teorizar rendimiento bajo un escenario como el que tengo. Lo malo es que, según explicas, estas en el caso opuesto al mío, trabajas dbExpress; pero nunca has trabajado BDE; así que creo que nos queda dificil comparar esa parte. Ojala alguién que conozca bien el funcionamiento interno de ambos productos pueda ilustranos.

El segundo punto es lo de la portabilidad a plataformas diferentes. Ese problema lo tengo resuelto de forma muy satisfactoria para mí. La pregunta fuerte es como manejar ese escenario con dbExpress. Digamos que tenemos el servidor usando dbExpress; pero el cliente es de otro fabricante de software. Puede ofrecernos dbExpress algo que mejore significativamente la metodología que uso ?. Tengo seria dudas porque al no tener el apoyo de la información originada en TClientDataset, supongo que tendría que hacerse esencialmente lo mismo que ya yo estoy haciendo.

El último punto es lo de los programas de pruebas. Fué por supuesto mi primera idea ya que a la hora de la verdad, ese sería el juez supremo; pero, dada la notable eficiencia que de por sí me ha demostrado el BDE y la complejidad de los modelos a emplear, para que la prueba sea realmente significativa el esfuerzo es grande y la considero solo como una opción extrema; por eso preferí tratar de documentarme teoricamente con la gente del foro.

Creo que si trabajas con servidores SQL (como es tu caso) te evitarás alguna capa intermedia. El drivers dbx funciona como un conector intermedio entre la aplicación y la librería de acceso al servidor SQL, la conexión es casi directa. Y precisamente tiene ese diseño para facilitar la portabilidad entre distintos SGBD. Nunca he utilizado BDE pero me parece que incluye una capa más (algo anticuada y sin desarrollo), el propio BDE. En comparación Dbx es mas liviano y directo y en consecuencia mas rápido y eficiente, o eso creo yo.

Lo suyo sería montar un pequeño programa test dual (DBX y BDE) y probar el rendimiento con inserciones, select y modificaciones masivas.

De todas formas sigo pensando que el problema para portar aplicaciones entre distintos SGBD sigue estando en el subconjunto de datos, SQL y "programación" en el servidor que contemple la aplicación. Respetando eso no habría problema de intercambiar algunos parámetros en el SQLConection y listo. Cosa distinta sería aprovechar la misma base para interfaces web.

[rolandoj]

Siento discrepar contigo, pero precisamente la "gracia" del TClientDataSet es que te permite trabajar de la misma manera independientemente de la base de datos que haya detrás. Fíjate, incluso podrías seguir con la filosofía que tienes de hacer por SQL directo (como tú dices) las actualizaciones manteniendo el desarrollo visual y los componentes enlazados a datos, que a fin de cuentas es lo que te permite ahorrarte un montón de tiempo en el desarrollo.

Hola,

Te agradezco el aporte.

Corrijeme si estoy equivocado; pero según entiendo, el TClientDataset captura los datos en pantalla y vía un provider se comunica con el DataSet final. Desde el punto de vista de trabajo de codificación eso es esencialmente lo mismo que hacemos con el BDE cuando usamos controles TDB conectados a un TTable vía TDatasource. La diferencia de rendimiento a favor del dbExpress es que lo hace con todo en cache con lo que cuando se guardan los datos se efectúa una transacción corta, en tanto que en BDE la transacción está abierta desde el inicio de la edición de datos.

En ese orden de ideas, el principio de independencia de Base de Datos es el mismo en el BDE como en el dbExpress. Como dije, apenas estoy empezando como dbExpress; pero me consta que funciona muy bien con BDE.

En mi metodología uso el mismo principio para trabajar también entre plataformas, enviando un solo bloque de datos al servidor cuando es necesario grabar; ese esquema dá independencia entre las herramientas de captura en pantalla y las de grabación de datos, ya que no hay intermediarios exigidos. La pregunta es : Como puede trabajarse con dbExpress de tal forma que se logre lo mismo y se haga en un tiempo significativamente menor ?.