Resumen Preg. sobre ADO, DAO y demas?

> -----Original Message-----
> From: owner-vb-esp@ccc.uba.ar [mailto:owner-vb-esp@ccc.uba.ar]On Behalf
> Of Leo
> Sent: Sunday, March 07, 1999 3:24 PM
> To: Lista VB
> Subject: (VB-ESP) Preg. sobre ADO, DAO y demas?
>
> Alguien, por favor, podría explicarme sintéticamente las diferencias?
>
> Gracias.

Artículo aún no publicado en mi columna en México:

DAO, RDO y ADO

El desarrollo de aplicaciones orientadas al manejo de bases de datos es uno de los más difundidos, no sólo en América Latina, sino en todo el mundo.
Cuando Visual Basic salió al mercado allá por 1991, no era ni la sombra de lo que es ahora. Los únicos servicios de datos con los que contaba era el acceso a archivos planos (Random, Texto y Binary), donde el programador tenía que ingeniárselas para emular un motor de bases de datos lo suficientemente convincente para hacer el trabajo. En la versión 2 (efímera, a todo esto), se presentó una modalidad de acceso a los datos que semejaba lo que luego fue conocido como DAO. Posteriormente, en la versión 4 se
presentó el RDO y, ahora, la versión 6 incluye ADO.

Todo está muy bien pero ¿qué significan estos acrónimos? ¿cuál tecnología me sirve? ¿son mutuamente excuyentes? ¿porqué la una y la otra? A estas alturas, ya se habrá encontrado con estos acrónimos dentro del entorno de Visual Basic y, ¿por qué no? de Delphi, Visual C++ y algunos otros. Todas estas tecnologías se basan en la tecnología de COM, por lo que pueden ser accedidas desde cualquier entorno de programación que lo soporte.

En fin, el día de hoy veremos lo que es cada una de estas tecnologías, y cual aplicar (en su caso) para el desarrollo de aplicaciones.

DAO
Este es el primer modelo de objetos de acceso a datos que se presentó con Visual Basic. De hecho, en sus orígenes no era, por mucho, un componente COM u OLE, por lo que su uso se restringía a VB3. Este modelo de objetos se llama Objetos de Acceso a Datos (DAO, Data Access Objects) y es todo un intrincado grupo de objetos y colecciones que permiten la completa administración de una base de datos del Jet.

El Jet (Tecnología de motores unidos o Joint Engine Technology) es el que le da vida a aplicaciones como Access para permitir el acceso a datos. Se llama "Tecnología de motores (motores de acceso a datos) unidos", pues el mismo motor permite el acceso a diversos formatos de bases de datos como MDB (Access), DBF (Clipper, dBASE, FoxPro, etcétera), Paradox, BTrieve, y archivos como XLS (Excel), WK? (Lotus) y TXT (Texto), entre otros.

Como se ve, este motor Jet es bastante pesadito, pues está obligado a realizar varias funciones en su interior. No obstante, permite una completa administración de la base de datos, muy en especial del formato MDB nativo. Cuenta con capacidades transaccionales, multiusuarios, seguridad (suficiente en muchos casos), y de red. Su uso se recomienda para bases de datos locales y en entornos de red donde la concurrencia de usuarios no sobrepase los 15 o 20, además de que la cantidad de datos no sobrepase 1GB.

Aunque ahora incluye características para el acceso directo a ODBC, no es el método más idóneo para hacer accesos a bases de datos que se ciñan a este estándar. Cuando se utiliza el control Data, se pueden facilitar muchos de los procesos de desarrollo de formularios de captura, aunque el desempeño se ve seriamente impactado negativamente.

RDO
Esta tecnología sólo funciona en 32 bits y fue presentada con la versión 4.0 de Visual Basic. Significa Objetos de Datos Remotos (Remote Data Objects), y está pensada para tener acceso a servidores de bases de datos RDBMS (Sistemas de Administración de Bases de datos Relacionales, Relational Database Management System) de alto nivel, como Oracle, Informix, SQL Server, etcétera.

A diferencia del DAO, RDO sólo hace conexiones directamente con la API de ODBC, lo cual le elimina la carga de un motor de bases de datos, que sí incluye DAO. No obstante, en funcionar como interfaz entre la API de ODBC y la aplicación, limita sobremanera sus características.

A pesar de ser una interfaz que pretende realizar un acceso consistente a todas las bases de datos ODBC, su comportamiento depende sustancialmente de las características del controlador ODBC del fabricante. A su vez, no pueden realizarse tareas de administración de la base de datos mediante RDO, pues este modelo de objetos sólo se pensó para facilitar el acceso a datos y ya.

Su funcionamiento óptimo, como puede inferirse de su instauración, se logra en redes LAN y algunos accesos transaccionales mediante Internet y CGI. No obstante, sus propias características (y las limitaciones de ODBC) no lo convierten en la mejor opción para aplicaciones Web (intranet, extranet e Internet), pues las conexiones deben ser permanentes.

De hecho, aún a través del Microsoft Transaction Server (o cualquier otro proveedor de transacciones, como Tuxedo), las conexiones RDO no son lo más recomendable para aplicaciones Web.

ADO
Este modelo de objetos, de reciente ingreso al mundo de la programación, fue diseñado para establecerse como el eslabón perdido entre DAO y RDO. En realidad ADO (Objetos ActiveX de Datos, o ActiveX Data Objects) sienta sus bases en la nueva tecnología OLEDB, que pretende reemplazar a ODBC, con varias ventajas. Entre las primordiales se encuentra el hecho de poder establecer prácticamente a cualquier origen de datos como proveedor de conjuntos de datos. Esto incluye no sólo a las bases de datos, sino también al correo electrónico y hasta servicios de directorios en red.

Así, OLEDB (que sólo funciona en Windows, hasta ahora) puede ser aprovechado para utilizar como origen de datos a prácticamente cualquier cosa que pueda organizarse en conjuntos de datos. Mediante ADO, es posible tener una interfaz hacia OLEDB y sus servicios. No obstante, el modelo de objetos ADO es el menor de los tres y permite la menor interacción con el origen de datos, aunque sí mayor velocidad de consecución de los datos.

Por añadidura, esta tecnología puede llevar a cabo conexiones a orígenes de datos, obtener conjuntos de resultados, almacenarlos "temporalmente" en la computadora local, desconectarse del servidor, trabajar con los datos obtenidos (modificarlos, eliminarlos, etcétera), y guardarlos en el servidor sin saturar la red.

Lo anterior convierte a esta tecnología en un serio candidato para ser utilizado en aplicaciones Web (intranet, extranet e Internet), así como una excelente opción para aplicaciones LAN y WAN donde el tráfico de la red sea bastante alto. Aún en aplicaciones con bases de datos locales, ADO podría dar buenos resultados, pues no se requeriría de aprender un nuevo conjunto de comandos para, entonces, hacer las conexiones acordes.

¿Cuál utilizar, entonces?
En realidad, como se infiere de los párrafos anteriores, las tres tecnologías tienen sus propias ventajas y desventajas. El ingreso de RDO al plano del desarrollo no deja fuera de la jugada a DAO. A su vez, ADO tampoco deja fuera de la jugada a RDO y DAO. De hecho, se notan claras diferencias entre una y otra tecnologías.

1. Si va a generar una aplicación que administre cercanamente la base de datos, permisos de accesos, y otras características propias de la base de datos; y que además maneje datos locales o en una red, cuya concurrencia de usuarios no supere los 20 y donde los datos por almacenar no supere 1GB, utilice DAO.

2. Si va a generar una aplicación que utilice un RDBMS de alto nivel, como SQL Server, Oracle, etcétera; y tal aplicación funcionará en un entorno LAN con conexiones ODBC, RDO será el candidato ideal.

3. Si va a generar una aplicación para redes LAN o WAN (intranet, extranet o Internet), con acceso a datos RDBMS conectadas indistintamente por OLEDB u ODBC, o que requieran hacer conexiones temporales para liberar el ancho de banda en la red, o que requieran del uso del Transaction Server, ADO es la tecnología recomendada.

Cabe indicar que la tecnología OLEDB es a la que le apuesta Microsoft en este momento. De hecho, el Jet 3.6 (que estará incluido en Access 2000), podrá accederse mediante OLEDB, aunque no estoy seguro que no pueda utilizarse de forma directa como hasta ahora se hace con DAO. El propio Microsoft indica que, por el estado de maduración en el que se encuentra ADO, podría ser prematuro decir que todas las aplicaciones con DAO y RDO se migren a ADO. No obstante, se recomienda hacerlo para aquellas que utilicen DAO con ODBCDirect.

Espero haberle apoyado con su decisión en estas tecnologías. No deje a DAO ni a RDO de lado. Ambos tienen su propio nicho. De hecho, RDO es la tecnología que podría tender a desaparecer en lugar del DAO, dado que el propio Microsoft presenta al DAO como la evolución de RDO. En fin, veremos qué es lo que después nos depara la empresa de las ventanas. ¡Nos seguimos leyendo!

+---¡Saludos desde México!--+
| .+'~~'+. |
| * Tron * David.BAS |
| `+,__,+' |
+---------------------------+
 http://www.spin.com.mx/~adgarza
adgarza@spin.com.mx



Resumen Resumen

Visual Basic Página de Visual Basic

Página principal Página principal

www.jrubi.com