FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Hay beneficio en migrar BDE a DBExpress bajo esta metodolgía ?
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 :
Y por tanto, un control transaccional luce algo así como
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. Última edición por rolandoj fecha: 29-08-2007 a las 23:19:57. |
#2
|
||||
|
||||
Bueno, BDE ya es una tecnologia "obsoleta" y dbExpress por el contraria se nota que ha recibido trabajo por parte de codegear....
__________________
El malabarista. |
#3
|
|||
|
|||
Gracias por la respuesta; pero ...
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. |
#4
|
|||
|
|||
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. |
#5
|
|||
|
|||
Gracias por la opinión. Comentarios
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 ? Cita:
|
#6
|
|||
|
|||
[
Cita:
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. Cita:
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.
__________________
Saludos. |
#7
|
|||
|
|||
Cita:
|
Herramientas | Buscar en Tema |
Desplegado | |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
El arroz que está llegando a nuestras mesas no está autorizado para consumo humano | sakuragi | La Taberna | 5 | 13-10-2013 00:07:14 |
Mejor herramienta de reportes costo/beneficio | saldanaluis | Impresión | 10 | 17-07-2007 20:46:42 |
de donde me bajo | gustavoh | Firebird e Interbase | 1 | 07-03-2005 19:28:27 |
|