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. (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. 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. 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. 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! :-D -- Lluís Franco i Montanyés [MS-MVP-MCP Visual Basic]