Contenido. Introducción

Transcripción

1 Migración de aplicaciones BDE a dbexpress La nueva tecnología utiliza la arquitectura proveer / resolver Por Bill Todd, Presidente de The Database Group, Inc. Para Borland Software Corporation Septiembre de 2002 Traducción por Pablo Reyes Para Danysoft Internacional, S.L. Contenido Primera Entrega Borland dbexpress - una nueva visión La arquitectura de dbexpress Cómo trabaja la arquitectura proveer / resolver Segunda Entrega Desarrollo de una aplicación dbexpress Tercera Entrega BDE versus dbexpress Migración de una aplicación SQL Links de BDE a dbexpress Migración de una aplicación de bases de datos de escritorio a dbexpress Introducción Este artículo, dividido en tres partes, está dedicado a la migración de aplicaciones BDE a dbexpress. En la primera entrega veremos las principales características de la nueva arquitectura proveer / resolver de dbexpress y las ventajas frente al BDE. En la segunda entrega veremos cómo desarrollar una aplicación dbexpress para familiarizarnos con esta nueva tecnología antes de migrar nuestras aplicaciones. En la tercera y última entrega veremos las tareas que tendremos que llevar a cabo para migrar nuestras aplicaciones BDE a dbexpress, ya sea que se traten de aplicaciones que utilicen servidor de bases de datos SQL o bases de datos de escritorio. Luego de haber leído las tres entregas de este artículo estaremos en condiciones de estimar el esfuerzo necesario para migrar nuestras aplicaciones BDE a dbexpress. Página: 1-5

2 Migración de aplicaciones BDE a dbexpress Esta es la primera entrega de un artículo dedicado a la migración de aplicaciones BDE a dbexpress. En total les ofreceremos tres entregas. Borland dbexpress - una nueva visión Todos los intentos hechos hasta al momento por crear un API común para múltiples bases de datos han tenido uno o más problemas. Algunos han sido grandes, lentos y difíciles de desplegar porque intentaban hacer demasiado. Otros han ofrecido un denominador común que impedía a los desarrolladores acceder a características especializadas de algunas bases de datos. Otros han tenido sufrido problemas derivados de la complejidad de escribir controladores, haciendo que sean limitados en funcionalidad, lentos y con errores. Borland dbexpress soluciona estos problemas combinando un nuevo enfoque para proveer un API común para muchas bases de datos con la probada arquitectura proveer / resolver de Borland para administrar el proceso de edición y actualización de datos. Este artículo examina la arquitectura de dbexpress y del mecanismo proveer / resolver, muestra como crear aplicaciones de bases de datos utilizando los componentes dbexpress y describe el proceso de convertir una aplicación que utiliza el BDE a dbexpress. La arquitectura de dbexpress dbexpress fue diseñado para cumplir los siguientes seis objetivos: Minimizar el tamaño y el uso de recursos del sistema. Maximizar la velocidad. Proveer soporte para plataforma cruzada. Proveer un despliegue más fácil. Hacer que el desarrollo de controladores sea más fácil. Darle al desarrollador más control sobre el uso de memoria y el tráfico de red. Los controladores dbexpress son pequeños y rápidos porque proveen funcionalidad muy limitada. Cada controlador es implementado como una única DLL en la plataforma Windows y como una única biblioteca de objetos compartidos en la plataforma Linux. Un controlador dbexpress implementa cinco interfaces que soportan la obtención de metadatos, la ejecución de sentencias SQL y procedimientos almacenados y la devolución de un cursor unidireccional de sólo-lectura como conjunto resultante. Sin embargo, cuando es utilizado con el DataSetProvider y el ClientDataSet para implementar la estrategia de acceso a datos proveer / resolver de Borland, dbexpress le da un sistema completo, de alto rendimiento y alta concurrencia para trabajar con datos en bases de datos SQL. Cómo trabaja la arquitectura proveer / resolver La arquitectura proveer / resolver utiliza cuatro componentes para proveer acceso a datos y edición. El primero es el componente SQLConnection que provee una conexión Página: 2-5

3 al controlador dbexpress de la base de datos que está utilizando. El siguiente es uno de los componentes DataSet de dbexpress que provee datos mediante la ejecución de sentencias SQL SELECT o llamadas a procedimientos almacenados. El tercer componente es el DataSetProvider y el cuarto el ClientDataSet. Cuando abre el ClientDataSet, solicita datos al DataSetProvider. El DataSetProvider abre el componente de consulta o procedimiento almacenado, obtiene los registros, cierra el componente de consulta o procedimiento almacenado y suministra los registros, con los metadatos requeridos, al ClientDataSet. El ClientDataSet mantiene los datos en memoria mientras son vistos y modificados. A medida que los registros son añadidos, eliminados o actualizados, ya sea por código o a través de la interface de usuario, el ClientDataSet registra todos los cambios en memoria. Para actualizar la base de datos, debe llamar al método ApplyUpdates del ClientDataSet. ApplyUpdates transmite el registro de cambios al DataSetProvider. El proveer inicia una transacción y luego crea y ejecuta sentencias SQL para aplicar los cambios en la base de datos. Si todos los cambios son aplicados exitosamente, el proveedor finaliza la transacción con commit; si no, la finaliza con rollback. La actualización de la base de datos puede fallar si, por ejemplo, un cambio viola las reglas del negocio forzadas por un disparador (trigger) o si otro usuario ha cambiado un registro que está intentando actualizar desde que lo leyó. Si ocurre un error, la transacción es finalizada con rollback y el evento OnReconcileError del ClientDataSet es disparado, dándole control sobre como es manejado el error. Beneficios de la arquitectura proveer / resolver Transacciones cortas Las transacciones largas fuerzan al servidor de bases de datos a mantener bloqueos, los cuales reducen la concurrencia y consumen recursos del servidor de bases de datos. Con la arquitectura proveer / resolver, las transacciones existen por un momento cuando se aplican las actualizaciones. Esto reduce dramáticamente el consumo de recursos y mejor la concurrencia en un servidor de bases de datos ocupado. Hace que cada fila se pueda editar Las filas devueltas por uniones de múltiples tablas, procedimientos almacenados o vistas de sólo-lectura no pueden ser editadas directamente. Mediante el uso de la propiedad ProviderFlags de los objetos TField para identificar los campos que deberían ser actualizados y el evento OnGetTableName del DataSetProvider para proveer el nombre de la tabla, muchos DataSet de sólo-lectura pueden ser actualizados fácilmente. Búsqueda y ordenación instantáneas Ya que el ClientDataSet mantiene los registros en memoria, pueden ser ordenados rápidamente. Si una ordenación en memoria es muy lenta, puede crear índices en el ClientDataSet en tiempo de diseño o ejecución. Estos índices en memoria le permiten cambiar el orden de visualización de los registro o localizar registros virtualmente en forma instantánea sin la sobre carga del mantenimiento de índices en la base de datos. Página: 3-5

4 Información resumida automáticamente El ClientDataSet mantendrá automáticamente complejos cálculos resumidos que defina, tales como Sum(Precio) - Sum(Coste). Puede agrupar cálculos resumidos por cualquier campo o combinaciones de campos para proveer totales por grupos. También puede utilizar los agregados Min (mínimo), Max (máximo), Count (cantidad) y Avg (promedio). Visualizar subconjuntos de datos Expresiones de filtrado utilizando sintaxis de SQL WHERE le permiten fácilmente mostrar un subconjunto de registros en un ClientDataSet sin la sobre carga de ejecutar otra consulta en el servidor de bases de datos. Múltiples vistas simultáneas de los datos La habilidad de clonar el cursor de un ClientDataSet le permite visualizar simultáneamente diferentes subconjuntos de datos del mismo ClientDataSet. También puede visualizar los mismos datos ordenados de manera diferente. Calcular campos sin sobrecargar el servidor Puede añadir campos calculados al ClientDataSet en tiempo de diseño para hacer de los campos calculados parte del DataSet en memoria. Ya que los cálculos son realizados utilizando código compilado del lenguaje Borland Delphi o C++, son rápidos y pueden ser mucho más complejos que columnas calculadas en una sentencia SQL o posibles cálculos en un procedimiento almacenado, ya que no imponen almacenamiento o carga computacional en el servidor de bases de datos. La limitación que no está ahí Mantener los registros en memoria parecería ser una limitación en cuanto a la cantidad de registros con las que puede trabajar. Sin embargo, considere que el diseño tradicional de las aplicaciones cliente / servidor ha sido siempre para seleccionar conjuntos de registro pequeños para minimizar el tráfico de red y la carga del servidor de bases de datos. Aun si tiene que trabajar con un número de registros inusualmente grande, recuerde que registros conteniendo 100 bytes cada uno, requiere sólo 1 megabyte de memoria. En el raro caso de que tenga que trabajar con un número de registros grande, el ClientDataSet y el DataSetProvider incluyen propiedades y eventos que le permiten obtener una porción de los registros, editarlos, removerlos de la memoria y obtener el siguiente grupo de registros. El despliegue es más fácil Las aplicaciones que utilizan dbexpress requieren sólo dos DLL para funcionar. la primera es el controlador dbexpress, por ejemplo, DBEXPINT.DLL en el caso de Borland InterBase, y la segunda es MIDAS.DLL, la biblioteca que soporta el uso del ClientDataSet. Juntas, estas dos DLL tiene un tamaño menor a medio megabyte. Esto minimiza el tamaño de la aplicación y simplifica la instalación. Si prefiere no distribuir estas DLL, las puede compilar directamente en su EXE. El despliegue en Linux es idéntico, excepto que las DLL son reemplazadas por bibliotecas de objetos compartidos. Página: 4-5

5 La creación de controladores es más fácil Los controladores dbexpress deben implementar sólo cinco interfaces que están descritas en la ayuda en línea. Además, Borland provee el código fuente del controlador para MySQL como modelo. Esto hace que sea más fácil para los vendedores de base de datos crear controladores robustos y de alto rendimiento. Incluso puede crear su propio controlador si está trabajando con una base de datos inusual o heredada y no hay un controlador comercial disponible. Página: 5-5