Artículo

Bueno, vamos a ver, esquematicemos un poco para simplificar et tema:

1) "Rendimiento degradado de MSDE con más de 5 o 8 usuarios, ¿es verdad?"

¿Que hay de cierto en todo esto? MSDE realmente TIENE LIMITACIONES, esto es cierto...y normal al mismo tiempo, ya que es el mismo motor de SQL Server y
claro... no puede ofrecer las mismas prestaciones de forma gratuita que un producto como SQL Server que tiene un coste importante.

<PEGO> (fuente: microsoft.com)
Como MSDE puede ser instalado con sus aplicaciones sin pago de regalías, tiene algunas restricciones:
- Tamaño de base de datos máximo de 2GB.
- Máximo de 8 sentencias procesadas en paralelo.
- Máximo de 16 instancias por máquina.
- No incluye herramientas de administración GUI.
</PEGO>

Dejando aparte el tamaño máximo de 2GB, hay que observar que el límite 'real' es de 8 sentencias procesadas 'concurrentemente', es decir al mismo tiempo. Lo cual quiere decir que en un sistema de 25 o 50 usuarios, si 8 de ellos están ejecutando simultáneamente sentencias en el servidor y aparece una nueva petición de un noveno usuario, ésta nueva petición quedará en cola hasta que el servidor termine con alguna de las 8 operaciones que estaba procesando. Y si queréis que os diga la verdad... esta degradación es mínima, por no decir nula en un sistema normal (es decir, un sistema que no sea una mega-aplicación con cientos de usuarios), ya que el tiempo que tarda el motor de SQL en 'despachar' una petición es infinitesimal en la mayoría de los casos.

Me gustaría saber cuantos de nosotros tenemos aplicaciones que trabajen con más de 8 usuarios haciendo operaciones concurrentemente, y en caso afirmativo preguntémonos ¿Está bien diseñada esta aplicación? ¿Cuántas veces ocurre esto a lo largo del tiempo? Muchas veces un buen diseño minimiza estos problemas de concurrencia... pero ¡no nos desviemos del tema!

Considerar 8 sentencias procesadas en paralelo como una limitación es de risa en la mayoría de los casos (ojo! No digo en todos), pero por mi parte considero peor no tener una interfaz del sistema de administración... y tener que crearme el mío propio o trabajar con scripts o vía consola.

Comentario añadido por marius:

Un apunte. Ya existe la nueva version de MSDE (SQL Server 2005 Express, esta en beta 2)
Diferencias entre MSDE2000 y 2005 Express:
De 2GB a 4GB
50 instancias por maquina
Incluye GUI
!!! Sin limitacion de sentencias. Las limitaciones las han implementado por RAM/CPU: de 2GB a 1GB y de 2CPUs a 1CPU.
El 2005 No soporta W98

Link: http://lab.msdn.microsoft.com/express/sql/

2) "Consideraciones de Rendimiento de Jet Engine vs. Cliente-Servidor"

No se puede hablar realmente de la eterna 'batalla' DAO vs. ADO, pero algo que ver tiene... aunque primero vamos a aclarar conceptos.

Partamos desde una clara premisa: Access es un gestor de bases de datos Desktop (de escritorio), no un servidor de bases de datos (SQL Server, Oracle) dicho esto, continuemos.

Access dispone de un maravilloso motor (Jet Engine) para procesar de forma NATIVA el acceso a los datos, y ya en sus inicios proporcionaba una interfaz programativa para acceder a los mismos llamada DAO (Data Access Objects), esta librería permitía a los desarrolladores acceso tanto a los datos (RecordSets), como a los Metadatos (TableDefs), como otras características que se fueron implementando posteriormente (Seguridad de usuarios/grupos), contenedores (Forms/Reports), etc... y al estar escrita únicamente para trabajar con el Jet Engine, su rendimiento era (y es) muy bueno.

¿Qué pasaba si queríamos acceder a otras bases de datos? Bueno, para ello teníamos el estándar ODBC del cual hablaremos luego, así que podíamos decir que teníamos dos sistemas de acceso a los datos:

a) DAO nativo para Jet

b) ODBC nativo para todo lo demás.

Perfecto!

Pero olvidamos algo... estamos hablando de rendimiento de DAO y no hemos hablado de volumen de datos ni de número de usuarios, y aquí está el talón de Aquiles del motor Jet.

Para acceder localmente a la información (en la misma estación) es el método más rápido existente... y de largo. Pero claro, la mayoría de aplicaciones no trabajan así, de forma que se comparte la información en una red local (o hasta externa), esto hace que debamos 'compartir' nuestro fichero mdb en un ordenador que actúe como SERVIDOR, y permitir que diversos ordenadores CLIENTES accedan a la información, pero realmente lo que estamos haciendo EN NINGÚN MOMENTO es una arquitectura cliente-servidor, sino únicamente un servidor de ficheros.

Esto provoca que cuando un cliente hace una petición (SELECT * FROM Clientes WHERE País = 'Brasil'), TODO el contenido de la tabla Clientes viaja por la red hasta el cliente, y allí el motor Jet local filtra la tabla y entrega sólo el resultado deseado a la aplicación. En un sistema cliente-servidor se envía la misma petición y el resultado es (simplificando el proceso) que el
servidor procesa y filtra la tabla clientes y devuelve únicamente los resultados solicitados. Esto provoca dos grandes ventajas, primera que el trabajo se centraliza en el servidor, que por lo general es una estación más potente que el cliente. Y segunda, los datos que viajan por la red son mínimos (y contra más registros tenemos en las tablas y más usuarios soliciten datos más notaremos esta ganancia).

Es por ello que el motor Jet se comporta muy bien en entornos de pocos usuarios o pocos registros, de hecho tengo varias aplicaciones funcionando en este entorno y no pienso cambiarlas, ya que dicho entorno no va a cambiar en un futuro próximo.

Con el tiempo, apareció un modelo llamado OLE DB que venía a ser la evolución natural de las dos tecnologías anteriores, ya que proporcionaba una nueva interfaz de acceso llamada ADO (ActiveX Data Objects), ello nos permitiría (teóricamente) escribir el mismo código para trabajar con 'cualquier' base de datos simplemente cambiando el proveedor (quito el proveedor de Access, pongo el de Oracle o SQL Server y funciona igual). Esto no es del todo cierto, pero se aproxima bastante...

Fantástico!

Sólo hay un pequeño detalle, DAO estaba escrito para funcionar únicamente con el motor Jet de forma nativa y ADO en cambio tiene que ser compatible con un modelo estándar, si a eso le añadimos que hay una capa intermedia que es el proveedor OLEDB, entenderemos la diferencia de rendimiento entre uno y otro (que por otra parte visto esto, tampoco es tanta).

Sin embargo ADO nos permite usar MSDE que si es plenamente una arquitectura cliente-servidor con todas sus ventajas (como el uso de procedimientos almacenados), y eso a su vez si hablamos de un sistema escalable que vaya creciendo con el tiempo, provocará que llegará un momento dónde el rendimiento será superior al uso de DAO.

Incluso si el sistema llegase a crecer tanto que incluso topásemos con las limitaciones mencionadas antes de MSDE, podríamos montar un servidor SQL Server, mover los datos con un par de clicks y ¡tenemos sistema para lustros!

Esta es la principal ventaja del uso de ADO respecto a DAO, su escalabilidad.

Comentario añadido por Antonio Ortiz:

Buena ilustracion, solo una observacion a tu comentario:

* No conozco exactamente como lo haga el Jet, pero mi logica me dice que NO traslada todo el contenido de la tabla, sino solo aquellos registros con los cuales 'compara' nuestro criterio. Claro esto dependera de los indices utilizados, asi como de la organizacion de las paginas de datos (urnas), el balance, etc. Recuerda que el Jet esta optimizado para este entorno (donde la aplicacion cliente accede directamente a los datos). La diferencia con un sistema cliente-servidor, es que esta 'comparacion' (query) o proceso se realiza del lado del servidor.

Puedes probar a crear una tabla con 5 millones de registros, colocala en una carpeta compartido, prueba el resultado de Select * From MiTabla Where ID=987656, donde ID es un indice primario (autonumerico), luego prueba a quitar el indice. Si el filtrado se hiciera de manera local, la diferencia seria minima, pues de cualquier manera existiria la carga de trasladar los 5 millones de registros, en este caso, aun cuando la base de datos se encuentre en un recurso compartido en la red local, el resultado sera casi instantaneo.

Comentario añadido por Valentín Playá Serra:

Yo creo que la verdad está en el medio.

Que toda la lógica esté en el cliente no quiere decir que no se usen los indices. Yo creo que la cosa funciona así: El cliente se trae el índice del servidor, busca el registro en el índice y solo trae el registro (o mejor la página donde está el registro) que necesita de la tabla principal.

Comentario añadido por Valentín Playá Serra:

Si no existen índices no le queda más remedio que traer página a página toda la tabla y seleccionar los registros que le pides. Aunque también puede usar técnicas más sofisticadas como crear una especie de índices temporales que le ayude a encontrar los valores que busca.

Lo que no puede hacer es pedirle al servidor que le devuelva un registro de una tabla, toda la lógica de búsqueda está en el cliente, de hecho el servidor puede no tener Access instalado, es un mero servidor de ficheros, no un servidor de Base de datos como SQL Server, Oracle y demás.

Comentario añadido por Lluís Franco:

Je, je... Dow! Me has pillado!
Efectivamente, tienes razón Antonio. He simplificado demasiado el ejemplo, así que lo que he dicho no es enteramente cierto... sólo aproximado.

"[...] The Microsoft Jet query engine implements a cost-based query optimizer. When a query is compiled, the query engine creates a query plan. This plan is used internally to find the quickest way to execute a query..."

De hecho el motor Jet de la estación cliente, basándose en los metadatos conocidos, parsea y compila el sql y crea un plan de ejecución, de forma que si realizamos como dices un 'Select * From MiTabla Where ID=987656', donde ID es un indice primario (autonumerico), el plan de ejecución utilizará el índice de la tabla para leer las páginas de memoria afectadas por los
registros reduciendo así en mucho el coste de la consulta.
De todas formas, es la librería local del cliente la que realiza el proceso, envía el SQL compilado, recoje los resultados y mantiene el cursor del conjunto de resultados (RecordSet).
No es en absoluto comparable al trabajo realizado en un servidor 'real' de bases de datos, pero algo hemos ganado.

Hay un par de artículos muy buenos acerca de técnicas de optimización del Jet engine y para los que usen ODBC en cliente-servidor:

Microsoft Jet 3.5 Performance Overview and Optimization Techniques
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnaraccessdev/html/ODC_MicrosoftOfficeDeveloperForumMicrosoftAccessMicrosoftJetDatabaseEngine.asp

Database Optimization Techniques
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnaraccessdev/html/ODC_DatabaseOptimizationTechniques.asp

Client-Server Application Development Using Microsoft Access (ODBC)
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnaraccessdev/html/ODC_AdvancedDataAccessObjectsDAOforClientServer.asp

3) "ODBC como opción al desarrollador"

La mayoría de nosotros alguna vez habremos necesitado acceder a tablas de un servidor corporativo (ya sea Oracle, SQL Server, Informix, etc...)
Como decíamos antes, el modelo ODBC era la solución para poder acceder a estos diversos sistemas, ya que existían los llamados drivers ODBC para casi todas las bases de datos, de forma que se instalaba el driver, se configuraba y listos.)

El modelo OLE DB terminó con esto al definir una arquitectura parecida pero con un mayor rendimiento al crear proveedores nativos para cada tipo distinto de servidor y al hecho de eliminar alguna de las capas intermedias en el proceso de acceso a los datos.

¿Cuándo hay que usar ODBC? Pues sinceramente, yo sólo lo usaría en el cada vez más improbable caso que tengamos que acceder a un servidor de bases de datos 'poco estándar' del cual no tengamos un proveedor OLE DB en el mercado y si uno de ODBC.

¿Entonces tenemos únicamente la opción ADO?

Para nada. Hoy en día, para crear una aplicación, en casi todos los distintos servidores de datos tenemos por lo menos dos formas de hacerlo:

a) Usar el modo NATIVO (DAO en Access, SQL-DMO en SQL Server, las librerías activeX de Oracle que no recuerdo ahora como se llaman, etc...).
Proporcionan un método de acceso más eficiente y potente pero no son estándares ni escalables, con lo cual si algún día queremos cambiar de servidor de datos tendremos que rescribir la aplicación.

b) Usar el modelo OLE DB, que proporciona un interfaz común de programación y escalabilidad garantizada sólo cambiando el proveedor (y haciendo cuatro retoques), a costa de perder un poco de rendimiento...

c) Algunas veces sólo podremos acceder usando ODBC (como MySQL), bueno... por lo que yo se, no existe un driver OLE DB, pero hace tiempo que no lo he vuelto a mirar.

La elección totalmente particular, en mi caso me decanto por la segunda... pero ¿con cual os quedarías vosotros?

En fin,
No pretendía enrollarme tanto, así que espero haber aclarado un par de conceptos y no haberos liado más (sig!)...

Y si alguien ha llegado a leer hasta aquí, pues... ¡gracias!