Ver Mensaje Individual
  #4  
Antiguo 24-05-2005
Avatar de mamcx
mamcx mamcx is offline
Moderador
 
Registrado: sep 2004
Ubicación: Medellín - Colombia
Posts: 3.917
Reputación: 25
mamcx Tiene un aura espectacularmamcx Tiene un aura espectacularmamcx Tiene un aura espectacular
Porque ADO es el API recomendado por MS... y el acceso por ODBC es "legacy". Ahora bien, con .NET se cambio la cosa, en vez de tener un esquema de acceso unificado que interfaza drivers especifico (como ODBC, ADO ) se cambio a uno no unificado con drivers y APIS especificos (existe el acceso por Sql, por ODBC, para Oracle pero no es unificado).

La verdad? El mejor desempeño se logra accesando de forma nativa la base de datos asi que las opciones globales como ODBC no son las de mejor desempeño.

Si quieres razones de peso toca solo un camino: Mide el desempeño en base al tipo de acceso que tendras (no es lo mismo multiples transacciones cortas de pocos registros que pocas transacciones largas de muchos registros) el hardware (memoria, cantidad de procesadores) el numero de conexiones concurrentes y el largo de las mismas , etc... entre cada componente.

Sin embargo, ten en cuenta que muchos problemas de desempeño se solucionan entendiendo la arquitectura de cada base de datos ... ademas la mayoria de los problemas de velocidad NO son por causa de la BD (cualquier motor SQL esta hecho para dar un desempeño adecuado, en terminos generales) sino de la manera como accesas los datos... Ademas los principales cuellos de botella son el ancho de banda y el disco duro.

En resumen? ADO te dara el desempeño adecuado. Pero igual sera ODBC o DBexpress y solo seran casos especificos donde las mejoras seran notorias.

Recomendacion? Lo mejor es poder cambiar de drivers sobre la marcha. Si necesitas esa habilidad el producto de www.remobjects.com llamado DataAbstract es lo mejor que conozco (permite modelar una BD virtual y usar multiples base de datos fisicas y drivers de datos para optimizar el acceso (por ejempo, usar un select para acces pero un procedimiento almacenado para Sql Server, pasar de ADO a DBExpress para Sql Server o componetes directos como SDAC y asi por el estilo).

La solucion economica pero mas larga es mas o menos lo que escribi en mi blog.

Sin embargo, si lo que necesitas es un desarrollo multi-nivel y acceso a muchas bases de datos SIN INSTALACIONES JARTAS DEL CLIENTE en este momento los productos de RemObjects, ASTA y Kbwm son los mejores (traduzco: Si tu aplicacion es importante te ahorraras MUCHO tiempo y tendras mucha funcionalidad.. ademas te dan el codigo fuente (y en particular con RemObjects que lo conozco esta muy bien hecho) asi que no te vas a quedar parqueado).
__________________
El malabarista.
Responder Con Cita