¿ ADO ?, ¿ RAO ?, ¿ DAO ?
Autor: David.BAS
adgarza@spin.com.mx
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 excluyentes? ¿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, (aunque teóricamente el
máximo es de 255 usuarios) además de que la cantidad
de datos no sobrepase 2GB .
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 (aunque
teóricamente el máximo es de 255 usuarios) y donde
los datos por almacenar no supere 2GB, 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 |
| `+,__,+' |
+---------------------------+
adgarza@spin.com.mx
