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:
Empezado por 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.
|