¿Cuál es la diferencia entre las fuentes de datos OLE DB y ODBC?


172

Estaba leyendo un artículo de ayuda de MS Excel sobre pivotcache y me pregunto qué quieren decir con fuentes OLE DB y ODBC

... Debe usar la propiedad CommandText en lugar de la propiedad SQL, que ahora existe principalmente para la compatibilidad con versiones anteriores de Microsoft Excel. Si usa ambas propiedades, el valor de la propiedad CommandText tiene prioridad.

Para las fuentes OLE DB , la propiedad CommandType describe el valor de la propiedad CommandText.

Para las fuentes ODBC , la propiedad CommandText funciona exactamente como la propiedad SQL, y establecer la propiedad hace que los datos se actualicen ...

Realmente aprecio tus respuestas cortas.


2
Solo una nota al margen, de acuerdo con este libro Implementando un Data Warehouse con Microsoft SQL Server 2012 : "Microsoft ha anunciado que en algún momento en el futuro cercano, el soporte para las conexiones OLE DB se eliminará a favor de las conexiones ODBC".
B. Burgdorf

2
Desde el 6 de octubre de 2017, está en desuso. Ver blogs.msdn.microsoft.com/sqlnativeclient/2017/10/06/…
Bogey Jammer

Respuestas:


148

Según ADO: ActiveX Data Objects , un libro de Jason T. Roff, publicado por O'Reilly Media en 2001 (excelente diagrama aquí), dice exactamente lo que dijo MOZILLA.

(directamente de la página 7 de ese libro)

  • ODBC proporciona acceso solo a bases de datos relacionales
  • OLE DB proporciona las siguientes características
    • Acceso a los datos independientemente de su formato o ubicación.
    • Acceso completo a fuentes de datos ODBC y controladores ODBC

Parece que OLE DB interactúa con fuentes de datos basadas en SQL a través de la capa de controlador ODBC.

texto alternativo

No estoy 100% seguro de que esta imagen sea correcta. Las dos conexiones de las que no estoy seguro son ADO.NET a través de ADO C-api y OLE DB a través de ODBC a una fuente de datos basada en SQL (porque en este diagrama el autor no pone el acceso de OLE DB a través de ODBC, lo cual creo es un error).


77
Si OLE DB usa ODBC para conectarse a fuentes de datos SQL, entonces cualquier fuente de datos SQL que sea compatible con OLE DB debería ser compatible con ODBC, sin embargo, este no es el caso: el diagrama original debe haber sido correcto (y no este )
Danny Varod

8
En realidad, a veces OLE DB envuelve el controlador ODBC, a veces no. Ver aquí
bobobobo

3
Esta entrada jamesmccaffrey.wordpress.com/2006/05/02/odbc-vs-ole-db dice que para SQL DS, OLEDB pasa por ODBC.
Hernán

1
@DannyVarod Ah, no importa. Perdí el calificador crítico en "cualquier fuente de datos SQL que sea compatible con OLE DB ...". Estaba hablando del hecho de que, dado que OLE DB admite fuentes de datos que no son RDBMS, es completamente posible que el conjunto sin filtrar de fuentes de datos compatibles con OLE DB sea un superconjunto de los compatibles con ODBC.
Asad Saeeduddin

44
ADO.NET no ajusta ADO. Las clases de ADO.NET generalmente hablan directamente con su base de datos o biblioteca de red de base de datos, no a través de cualquier otra capa de proveedor / controlador. Por ejemplo, System.Data.SqlClientmaneja el protocolo TDS en código administrado, solo usando código nativo para manejar la transmisión TCP / Named Pipes / etc a través de la red. Para las bases de datos que no tienen un proveedor administrado propio, puede usar System.Data.OleDbpara ajustar OLE DB o System.Data.Odbcpara ajustar ODBC, pero no se recomienda.
Mike Dimmick

55

ODBC: - Solo para bases de datos relacionales (Sql Server, Oracle, etc.)

OLE DB: - Para bases de datos relacionales y no relacionales. (Oracle, SQL Server, Excel, archivos sin formato, etc.)


44
Incorrecto, ambos pueden hablar con tiendas no relacionales dependiendo de los controladores.
Andy Dent

1
No, con ODBC puede consultar incluso archivos CSV planos, no solo bases de datos relacionales.
Wernfried Domscheit

¡Incorrecto! También hay un archivo de texto y un controlador XML ODBC.
Scott Chu

1
Creo que esto no es correcto ... Open Database Connectivity (ODBC) is Microsoft's strategic interface for accessing data in a heterogeneous environment of relational and non- relational database management systems. support.microsoft.com/en-us/kb/110093
uzay95

11
jajaja, ustedes están hablando de ODBC en 2009 o 2016 ...? Fue correcto.
Yousha Aleayoub

42

Aquí está mi comprensión (no autorizada):

ODBC es un estándar abierto independiente de la tecnología compatible con la mayoría de los proveedores de software. OLEDB es una API de Microsoft específica de la tecnología de la era COM (COM era una tecnología de componentes e interoperabilidad antes de .NET)

En algún momento, varios proveedores de bases de datos (por ejemplo, Oracle, etc.), dispuestos a ser compatibles con los consumidores de datos de Microsoft, desarrollaron proveedores OLEDB para sus productos, pero en su mayor parte OLEDB sigue siendo un estándar exclusivo de Microsoft. Ahora, la mayoría de las fuentes de datos de Microsoft permiten el acceso tanto a ODBC como a OLEDB, principalmente por compatibilidad con los consumidores de datos heredados de ODBC. Además, existe un proveedor OLEDB (contenedor) para ODBC que le permite a uno usar OLEDB para acceder a las fuentes de datos ODBC si así lo desea.

En términos de las características, OLEDB es sustancialmente más rico que ODBC pero sufre del síndrome de un anillo para gobernarlos a todos (demasiado genérico, demasiado complicado, no es obstinado).

En el mundo que no es de Microsoft, los proveedores y clientes de datos basados ​​en ODBC son ampliamente utilizados y no van a ninguna parte.

Dentro de la burbuja de Microsoft, OLEDB se está eliminando gradualmente a favor de las API nativas de .NET construidas sobre cualquier capa de transporte nativa para esa fuente de datos (por ejemplo, TDS para MS SQL Server).


20

ODBC y OLE DB son dos tecnologías de acceso a datos competidoras. Específicamente con respecto a SQL Server, Microsoft los ha promocionado a ambos como su Dirección Futura Preferida, aunque en diferentes momentos.

ODBC

ODBC es una interfaz estándar de toda la industria para acceder a datos similares a tablas. Fue desarrollado principalmente para bases de datos y presenta datos en colecciones de registros, cada uno de los cuales se agrupa en una colección de campos. Cada campo tiene su propio tipo de datos adecuado para el tipo de datos que contiene. Cada proveedor de base de datos (Microsoft, Oracle, Postgres, ...) proporciona un controlador ODBC para su base de datos.

También hay controladores ODBC para objetos que, aunque no son tablas de base de datos, son lo suficientemente similares como para acceder a los datos de la misma manera. Ejemplos son hojas de cálculo, archivos CSV e informes en columnas.

OLE DB

OLE DB es una tecnología de Microsoft para el acceso a datos. A diferencia de ODBC, abarca datos con y sin formato de tabla, como mensajes de correo electrónico, páginas web, documentos de Word y directorios de archivos. Sin embargo, está orientado a procedimientos más que a objetos y se considera una interfaz bastante difícil para desarrollar el acceso a las fuentes de datos. Para superar esto, ADO fue diseñado para ser una capa orientada a objetos sobre OLE DB y para proporcionar una forma más simple y de alto nivel, aunque aún muy poderosa, de trabajar con ella. La gran ventaja de ADO es que puede usarlo para manipular propiedades que son específicas de un tipo determinado de fuente de datos, tan fácilmente como puede usarlo para acceder a esas propiedades que se aplican a todos los tipos de fuentes de datos. No está restringido a algún mínimo común denominador insatisfactorio.

Si bien todas las bases de datos tienen controladores ODBC, no todas tienen controladores OLE DB. Sin embargo, hay una interfaz disponible entre OLE y ODBC que se puede utilizar si desea acceder a ellas de forma similar a OLE DB. Esta interfaz se llama MSDASQL (proveedor Microsoft OLE DB para ODBC).

Tecnologías de acceso a datos de SQL Server

Dado que SQL Server es (1) creado por Microsoft y (2) la plataforma de base de datos de Microsoft, tanto ODBC como OLE DB son ideales para ello.

ODBC

Como todas las demás plataformas de bases de datos tenían interfaces ODBC, Microsoft obviamente tenía que proporcionar una para SQL Server. Además de esto, DAO, la tecnología predeterminada original en Microsoft Access, utiliza ODBC como la forma estándar de hablar con todas las fuentes de datos externas. Esto hizo que una interfaz ODBC fuera una condición sine qua non. El controlador ODBC de la versión 6 para SQL Server, lanzado con SQL Server 2000, todavía está disponible. Se han lanzado versiones actualizadas para manejar los nuevos tipos de datos, tecnologías de conexión, cifrado, HA / DR, etc. que han aparecido con versiones posteriores. A partir del 07/09/2018, la versión más reciente es v13.1 "Controlador ODBC para SQL Server", lanzado el 23/03/2018.

OLE DB

Esta es la tecnología propia de Microsoft, que estaban promoviendo fuertemente desde aproximadamente 2002 - 2005, junto con su capa ADO. Evidentemente, esperaban que se convirtiera en la tecnología de acceso a datos de elección. (Incluso hicieron de ADO el método predeterminado para acceder a los datos en Access 2002/2003.) Sin embargo, eventualmente se hizo evidente que esto no iba a suceder por varias razones, tales como:

  1. El mundo no iba a convertirse a las tecnologías de Microsoft y lejos de ODBC;
  2. DAO / ODBC era más rápido que ADO / OLE DB y también estaba completamente integrado en MS Access, por lo que no iba a morir de muerte natural;
  3. Las nuevas tecnologías desarrolladas por Microsoft, específicamente ADO.NET, también podrían comunicarse directamente con ODBC. ADO.NET también podía hablar directamente con OLE DB (dejando a ADO en un remanso), pero no era (a diferencia de ADO) únicamente dependiente de él.

Por estas y otras razones , Microsoft desaprobó OLE DB como tecnología de acceso a datos para las versiones de SQL Server después de v11 (SQL Server 2012). Durante un par de años antes de este punto, habían estado produciendo y actualizando el SQL Server Native Client, que era compatible con las tecnologías ODBC y OLE DB. Sin embargo, a fines de 2012 anunciaron que se alinearían con ODBC para el acceso de datos relacionales nativos en SQL Server, y alentaron a todos los demás a hacer lo mismo. Afirmaron además que las versiones de SQL Server después de v11 / SQL Server 2012 no admitirían activamente OLE DB.

Este anuncio provocó una tormenta de protestas. Las personas no sabían por qué la EM de repente estaba desaprobando una tecnología con la que habían pasado años haciendo que se comprometieran. Además, SSAS / SSRS y SSIS, que eran aplicaciones escritas en MS íntimamente vinculadas a SQL Server, dependían total o parcialmente de OLE DB. Otra queja más fue que OLE DB tenía ciertas características deseables que parecía imposible trasladar a ODBC; después de todo, OLE DB tenía muchos puntos positivos.

En octubre de 2017, Microsoft cedió y oficialmente dejó de usar OLE DB . Anunciaron la inminente llegada de un nuevo controlador (MSOLEDBSQL) que tendría el conjunto de características existente del Native Client 11 y también introduciría la conmutación por error de múltiples subredes y el soporte TLS 1.2. El controlador fue lanzado en marzo de 2018.


@ChieltenBrinke Emparejé la publicación de varias fuentes, como los enlaces que actualicé para incluir y, no menos importante, los comentarios que provocaron. Otras fuentes fueron el libro de Jason Roff sobre ADO mencionado por bobobobo, y The Access 2002 Desktop Developer Handbook, de Litwin, Getz y Gunderloy (muy antiguo, pero un verdadero clásico). No tengo ningún tipo de información privilegiada en Microsoft, por lo que mis especulaciones sobre el pensamiento detrás de sus diversos cambios de dirección, aunque plausibles, son totalmente mías.
marktwo

6

En un nivel muy básico, esas son solo API diferentes para las diferentes fuentes de datos (es decir, bases de datos). OLE DB es más nuevo y posiblemente mejor.

Puedes leer más sobre ambos en Wikipedia:

  1. OLE DB
  2. ODBC

Es decir, puede conectarse a la misma base de datos utilizando un controlador ODBC o un controlador OLE DB. La diferencia en el comportamiento de la base de datos en esos casos es a qué se refiere su libro.


44
Como con muchos temas relacionados con TI, las cosas casi han cerrado el círculo. SQL 2012 fue la última versión para admitir el proveedor nativo OLE DB y las aplicaciones ahora deberían cambiar a ODBC posterior. como los "viejos tiempos" de SQL Server technet.microsoft.com/en-us/library/hh967418.aspx
Chris Wood

44
"OLE DB es más nuevo y posiblemente mejor" esto puede haber sido cierto en 2008 pero no en 2014.
Michael David Watson

@MichaelDavidWatson Entonces, ¿qué dirías? ¿Mejor uso de ODBC o OLEDB? Necesito admitir tantas bases de datos SQL como sea posible. Y como señala, OLE DB también puede acceder a una fuente de datos ODBC. Entonces, ¿por qué diría que "OLE DB es más nuevo y posiblemente mejor" sigue siendo incorrecto en 2015? :)
LuckyLikey

@LuckyLikey MS ha desaprobado OLEDB y SQL Server ya no lo admite (SS 2012 fue el último en admitirlo). msdn.microsoft.com/en-us/library/hh967418.aspx
Robino

5

Ambos son proveedores de datos (API que usará su código para hablar con una fuente de datos). Oledb, que se introdujo en 1998, estaba destinado a ser un reemplazo de ODBC (introducido en 1992)



3

No estoy seguro de todos los detalles, pero entiendo que OLE DB y ODBC son dos API que están disponibles para conectarse a varios tipos de bases de datos sin tener que lidiar con todos los detalles específicos de implementación de cada uno. De acuerdo con el artículo de Wikipedia sobre OLE DB , OLE DB es el sucesor de ODBC de Microsoft y proporciona algunas características que es posible que no pueda hacer con ODBC, como acceder a hojas de cálculo como fuentes de bases de datos.


2

En el sitio web de Microsoft, muestra que el proveedor OLEDB nativo se aplica al servidor SQL directamente y otro proveedor OLEDB llamado OLEDB Provider para que ODBC acceda a otra Base de Datos, como Sysbase, DB2, etc. Hay diferentes tipos de componentes bajo OLEDB Provider. Consulte Consultas distribuidas en MSDN para obtener más información.


0

ODBC funciona solo para bases de datos relacionales, no puede funcionar con bases de datos no relacionales como los archivos Ms Excel. Donde Olebd puede hacer todo.


-3

Para saber por qué M $ inventa OLEDB, no se puede comparar OLEDB con ODBC. En su lugar, debe comparar OLEDB con DAO, RDO o ADO. Este último se basa en gran medida en SQL. Sin embargo, OLEDB se basa en COM. Pero ODBC ya está allí muchos años, por lo que hay puentes OLEDB-ODBC para remediar esto. Creo que hay una gran imagen cuando M $ inventa OLEDB.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.