Jaka jest różnica między źródłami danych OLE DB i ODBC?

171

Czytałem artykuł pomocy MS Excel o pivotcache i zastanawiałem się, co oznaczają źródła OLE DB i ODBC

... Należy użyć właściwości CommandText zamiast właściwości SQL, która obecnie istnieje głównie w celu zapewnienia zgodności z wcześniejszymi wersjami programu Microsoft Excel. Jeśli używasz obu właściwości, pierwszeństwo ma wartość właściwości CommandText.

W przypadku źródeł OLE DB właściwość CommandType opisuje wartość właściwości CommandText.

W przypadku źródeł ODBC właściwość CommandText działa dokładnie tak samo, jak właściwość SQL, a ustawienie właściwości powoduje odświeżenie danych ...

Naprawdę doceniam twoje krótkie odpowiedzi.

Martin08
źródło
2
Na marginesie, zgodnie z tą książką Implementing a Data Warehouse with Microsoft SQL Server 2012 : „Microsoft ogłosił, że w niedalekiej przyszłości obsługa połączeń OLE DB zostanie usunięta na korzyść połączeń ODBC”.
B. Burgdorf
2
Od 6 października 2017 r. Nie jest chwalony. Zobacz blogs.msdn.microsoft.com/sqlnativeclient/2017/10/06/…
Bogey Jammer

Odpowiedzi:

147

Według ADO: ActiveX Data Objects , książki Jasona T. Roffa, opublikowanej przez O'Reilly Media w 2001 roku (doskonały diagram tutaj), mówi dokładnie to, co powiedział MOZILLA.

(bezpośrednio ze strony 7 tej książki)

  • ODBC zapewnia dostęp tylko do relacyjnych baz danych
  • OLE DB zapewnia następujące funkcje
    • Dostęp do danych niezależnie od ich formatu czy lokalizacji
    • Pełny dostęp do źródeł danych ODBC i sterowników ODBC

Wydawałoby się więc, że OLE DB współdziała ze źródłami danych opartymi na SQL poprzez warstwę sterownika ODBC.

tekst alternatywny

Nie jestem w 100% pewien, czy ten obraz jest poprawny. Dwa połączenia, których nie jestem pewien, to ADO.NET przez ADO C-api i OLE DB przez ODBC do źródła danych SQL (ponieważ na tym diagramie autor nie umieszcza dostępu OLE DB przez ODBC, co moim zdaniem jest błędem).

bobobobo
źródło
7
Jeśli OLE DB używa ODBC do łączenia się ze źródłami danych SQL, to każde źródło danych SQL obsługiwane przez OLE DB musiałoby być obsługiwane przez ODBC, jednak tak nie jest - oryginalny diagram musiał być poprawny (a nie ten ).
Danny Varod
8
W rzeczywistości czasami OLE DB zawija sterownik ODBC, czasami nie. Zobacz tutaj
bobobobo
3
Ten wpis jamesmccaffrey.wordpress.com/2006/05/02/odbc-vs-ole-db mówi, że w przypadku SQL DS OLEDB przechodzi przez ODBC.
Hernán
1
@DannyVarod Ah, nieważne. Brakowało mi krytycznego kwalifikatora w „każdym źródle danych SQL, które jest obsługiwane przez OLE DB,…”. Mówiłem o tym, że skoro OLE DB obsługuje źródła danych inne niż RDBMS, jest całkowicie możliwe, że niefiltrowany zestaw źródeł danych obsługiwanych przez OLE DB będzie nadzbiorem tych obsługiwanych przez ODBC.
Asad Saeeduddin
4
ADO.NET nie zawija ADO. Klasy ADO.NET generalnie komunikują się bezpośrednio ze swoimi bazami danych lub bibliotekami sieciowymi baz danych, a nie przez jakąkolwiek inną warstwę dostawcy / sterownika. Na przykład System.Data.SqlClientobsługuje protokół TDS w kodzie zarządzanym, używając tylko kodu natywnego do obsługi transmisji TCP / Named Pipes / etc przez sieć. W przypadku baz danych, które nie mają własnego zarządzanego dostawcy, można użyć System.Data.OleDbdo zawijania OLE DB lub System.Data.Odbcdo zawijania ODBC, ale nie jest to zalecane.
Mike Dimmick
55

ODBC: - Tylko dla relacyjnych baz danych (Sql Server, Oracle itp.)

OLE DB: - dla relacyjnych i nierelacyjnych baz danych. (Oracle, Sql-Server, Excel, pliki RAW itp.)

MOZILLA
źródło
4
Źle, obaj mogą rozmawiać z nierelacyjnymi sklepami w zależności od kierowców.
Andy Dent
1
Nie, dzięki ODBC możesz przeszukiwać nawet płaskie pliki CSV, a nie tylko relacyjne bazy danych.
Wernfried Domscheit
Źle! Jest też plik tekstowy i sterownik XML ODBC.
Scott Chu,
1
Myślę, że to nie jest poprawne ... 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
lol, mówicie o ODBC w 2009 lub 2016 roku ...? to było poprawne.
Yousha Aleayoub
42

Oto moje zrozumienie (nieautorytatywne):

ODBC to otwarty standard niezależny od technologii, obsługiwany przez większość dostawców oprogramowania. OLEDB to specyficzny dla technologii interfejs API firmy Microsoft z ery COM (COM był komponentem i technologią współdziałania przed .NET)

W pewnym momencie różni dostawcy danych (np. Oracle itp.), Chcąc być zgodni z konsumentami danych firmy Microsoft, opracowali dostawców OLEDB dla swoich produktów, ale w większości OLEDB pozostaje standardem wyłącznie dla firmy Microsoft. Obecnie większość źródeł danych firmy Microsoft umożliwia dostęp zarówno do ODBC, jak i OLEDB, głównie w celu zapewnienia zgodności ze starszymi odbiorcami danych ODBC. Istnieje również dostawca OLEDB (opakowanie) dla ODBC, który pozwala na użycie OLEDB w celu uzyskania dostępu do źródeł danych ODBC, jeśli sobie tego życzy.

Pod względem funkcji OLEDB jest znacznie bogatszy niż ODBC, ale cierpi na zespół jednego pierścienia, aby rządzić wszystkimi (zbyt ogólny, nadmiernie skomplikowany, nieoparty).

W świecie innym niż Microsoft dostawcy danych i klienci bazujący na ODBC są szeroko wykorzystywani i nigdzie nie idą.

Wewnątrz Microsoft bubble OLEDB jest wycofywany na rzecz natywnych interfejsów .NET API zbudowanych na podstawie natywnej warstwy transportowej dla tego źródła danych (np. TDS dla MS SQL Server).

zvolkov
źródło
20

ODBC i OLE DB to dwie konkurujące ze sobą technologie dostępu do danych. W szczególności w odniesieniu do SQL Server, Microsoft promował oba z nich jako preferowany kierunek przyszłości - choć w różnym czasie.

ODBC

ODBC to branżowy standardowy interfejs umożliwiający dostęp do danych tabelarycznych. Został opracowany przede wszystkim dla baz danych i prezentuje dane w zbiorach rekordów, z których każdy jest pogrupowany w zbiór pól. Każde pole ma swój własny typ danych, odpowiedni dla typu zawartych w nim danych. Każdy dostawca baz danych (Microsoft, Oracle, Postgres,…) dostarcza sterownik ODBC dla swojej bazy danych.

Istnieją również sterowniki ODBC dla obiektów, które choć nie są tabelami bazy danych, są na tyle podobne, że dostęp do danych w ten sam sposób jest przydatny. Przykładami są arkusze kalkulacyjne, pliki CSV i raporty kolumnowe.

OLE DB

OLE DB to technologia firmy Microsoft umożliwiająca dostęp do danych. W przeciwieństwie do ODBC obejmuje zarówno dane tabelaryczne, jak i inne niż tabelaryczne, takie jak wiadomości e-mail, strony internetowe, dokumenty programu Word i katalogi plików. Jest jednak zorientowany raczej na procedury niż obiektowo i jest uważany za dość trudny interfejs, za pomocą którego można rozwijać dostęp do źródeł danych. Aby temu zaradzić, ADO został zaprojektowany jako warstwa zorientowana obiektowo na wierzchu OLE DB i aby zapewnić prostszy i wyższy poziom - choć wciąż bardzo potężny - sposób pracy z nim. Ogromną zaletą ADO jest to, że można go używać do manipulowania właściwościami specyficznymi dla danego typu źródła danych, tak samo łatwo, jak można go używać do uzyskiwania dostępu do właściwości, które mają zastosowanie do wszystkich typów źródeł danych. Nie jesteś ograniczony do jakiegoś niezadowalającego najniższego wspólnego mianownika.

Chociaż wszystkie bazy danych mają sterowniki ODBC, nie wszystkie mają sterowniki OLE DB. Istnieje jednak interfejs między OLE i ODBC, którego można użyć, jeśli chcesz uzyskać do nich dostęp w sposób podobny do OLE DB. Ten interfejs nosi nazwę MSDASQL (dostawca Microsoft OLE DB dla ODBC).

Technologie dostępu do danych programu SQL Server

Ponieważ SQL Server jest (1) produkowany przez Microsoft i (2) jest platformą bazodanową Microsoft, zarówno ODBC, jak i OLE DB są dla niego naturalnym rozwiązaniem.

ODBC

Ponieważ wszystkie inne platformy bazodanowe miały interfejsy ODBC, Microsoft oczywiście musiał dostarczyć jeden dla SQL Server. Oprócz tego DAO, oryginalna domyślna technologia w programie Microsoft Access, używa ODBC jako standardowego sposobu komunikowania się ze wszystkimi zewnętrznymi źródłami danych. To sprawiło, że interfejs ODBC stał się warunkiem sine qua non. Sterownik ODBC w wersji 6 dla SQL Server, wydany wraz z SQL Server 2000, wciąż jest dostępny. Zostały wydane zaktualizowane wersje obsługujące nowe typy danych, technologie połączeń, szyfrowanie, HA / DR itp., Które pojawiły się w kolejnych wersjach. Od 09/07/2018 najnowszą wersją jest 13.1 „Sterownik ODBC dla SQL Server”, wydana 23.03.2018.

OLE DB

To własna technologia Microsoftu, którą intensywnie promował w latach 2002-2005 wraz z towarzyszącą jej warstwą ADO. Najwyraźniej mieli nadzieję, że stanie się to preferowaną technologią dostępu do danych. (Uczynili nawet ADO domyślną metodą uzyskiwania dostępu do danych w programie Access 2002/2003). Ostatecznie jednak okazało się, że nie stanie się to z wielu powodów, takich jak:

  1. Świat nie zamierzał przejść na technologie Microsoft i odejść od ODBC;
  2. DAO / ODBC był szybszy niż ADO / OLE DB i był również całkowicie zintegrowany z MS Access, więc nie umarł śmiercią naturalną;
  3. Nowe technologie opracowywane przez Microsoft, w szczególności ADO.NET, mogą również komunikować się bezpośrednio z ODBC. ADO.NET mógł również rozmawiać bezpośrednio z OLE DB (pozostawiając ADO w zaścianku), ale nie był (w przeciwieństwie do ADO) wyłącznie od niego zależny.

Z tych i innych powodów firma Microsoft faktycznie wycofała OLE DB jako technologię dostępu do danych dla wersji SQL Server po wersji v11 (SQL Server 2012). Przez kilka lat wcześniej tworzyli i aktualizowali SQL Server Native Client, który obsługiwał zarówno technologie ODBC, jak i OLE DB. Jednak pod koniec 2012 roku ogłosili, że będą dostosowywać się do ODBC w celu uzyskania natywnego dostępu do danych relacyjnych w SQL Server i zachęcali wszystkich do zrobienia tego samego. Ponadto stwierdził, że ich wersje SQL Server po v11 / SQL Server 2012 będzie aktywnie nie obsługują OLE DB!

To ogłoszenie wywołało burzę protestów. Ludzie nie mogli zrozumieć, dlaczego stwardnienie rozsiane nagle zaczęło deprecjonować technologię, na którą musieli się zaangażować przez lata. Ponadto SSAS / SSRS i SSIS, które były aplikacjami napisanymi przez MS, ściśle powiązanymi z SQL Server, były całkowicie lub częściowo zależne od OLE DB. Kolejnym zarzutem było to, że OLE DB miał pewne pożądane funkcje, których przeniesienie z powrotem do ODBC wydawało się niemożliwe - w końcu OLE DB miał wiele zalet.

W październiku 2017 roku Microsoft ustąpił i oficjalnie wycofał OLE DB . Ogłosili rychłe nadejście nowego sterownika (MSOLEDBSQL), który będzie miał istniejący zestaw funkcji klienta natywnego 11, a także wprowadzi przełączanie awaryjne wielu podsieci i obsługę protokołu TLS 1.2. Sterownik został wydany w marcu 2018 roku.

marktwo
źródło
@ChieltenBrinke Zebrałem post z kilku źródeł, takich jak linki, które zaktualizowałem, aby zawierały, a także komentarze, które wywołały. Innymi źródłami były książka Jasona Roffa o ADO, o której wspomniał bobobobo, oraz The Access 2002 Desktop Developer's Handbook, autorstwa Litwina, Getza i Gunderloya (naprawdę stara, ale prawdziwa klasyka). W firmie Microsoft nie mam żadnego wewnętrznego tropu, więc moje spekulacje co do sposobu myślenia stojącego za różnymi zmianami kierunku, choć prawdopodobne, są całkowicie moje.
marktwo
6

Na bardzo podstawowym poziomie są to po prostu różne API dla różnych źródeł danych (tj. Baz danych). OLE DB jest nowszy i prawdopodobnie lepszy.

Możesz przeczytać więcej na temat obu w Wikipedii:

  1. OLE DB
  2. ODBC

Oznacza to, że można połączyć się z tą samą bazą danych za pomocą sterownika ODBC lub sterownika OLE DB. Różnica w zachowaniu bazy danych w tych przypadkach jest tym, do czego odnosi się twoja książka.

Ilya Kochetov
źródło
4
Podobnie jak w przypadku wielu tematów związanych z IT, sprawy zatoczyły prawie pełne koło. SQL 2012 był ostatnią wersją obsługującą natywnego dostawcę OLE DB i aplikacje powinny teraz przełączyć się na wsteczną technologię ODBC. jak „dawne czasy” SQL Server technet.microsoft.com/en-us/library/hh967418.aspx
Chris Wood
4
„OLE DB jest nowszy i prawdopodobnie lepszy” to może być prawdą w 2008 roku, ale nie w 2014 roku.
Michael David Watson
@MichaelDavidWatson Więc co byś powiedział. Lepiej korzystać z ODBC lub OLEDB? Muszę obsługiwać jak najwięcej różnych baz danych SQL. Jak wskazuje, OLE DB może również uzyskiwać dostęp do źródła danych ODBC. Dlaczego więc powiedziałbyś, że „OLE DB jest nowszy i prawdopodobnie lepszy” nadal jest niepoprawne w 2015 roku? :)
LuckyLikey
@LuckyLikey MS wycofał OLEDB, a SQL Server już go nie obsługuje (SS 2012 był ostatnim, który go obsługiwał). msdn.microsoft.com/en-us/library/hh967418.aspx
Robino,
5

Obaj są dostawcami danych (API, którego Twój kod będzie używać do komunikacji ze źródłem danych). Oledb, który został wprowadzony w 1998 roku, miał zastąpić ODBC (wprowadzony w 1992)

Arcturus
źródło
3

Nie jestem pewien wszystkich szczegółów, ale rozumiem, że OLE DB i ODBC to dwa interfejsy API, które są dostępne do łączenia się z różnymi typami baz danych bez konieczności zajmowania się wszystkimi szczegółami dotyczącymi implementacji każdego z nich. Zgodnie z artykułem Wikipedii na temat OLE DB , OLE DB jest następcą ODBC firmy Microsoft i zapewnia pewne funkcje, których możesz nie być w stanie wykonać z ODBC, takie jak dostęp do arkuszy kalkulacyjnych jako źródeł baz danych.

user10340
źródło
2

Na stronie firmy Microsoft widać, że natywny dostawca OLEDB jest stosowany bezpośrednio do serwera SQL, a inny dostawca OLEDB o nazwie OLEDB Provider dla ODBC w celu uzyskania dostępu do innych baz danych, takich jak Sysbase, DB2 itp. W ramach dostawcy OLEDB istnieją różne rodzaje komponentów. Aby uzyskać więcej informacji, zobacz Zapytania rozproszone w witrynie MSDN .

FebWind
źródło
0

ODBC działa tylko w przypadku relacyjnych baz danych, nie może działać z nierelacyjnymi bazami danych, takimi jak pliki Ms Excel. Gdzie Olebd może zrobić wszystko.

Md Shahriar
źródło
-3

Aby wiedzieć, dlaczego M $ wymyśla OLEDB, nie można porównać OLEDB z ODBC. Zamiast tego powinieneś porównać OLEDB z DAO, RDO lub ADO. Ten ostatni w dużej mierze opiera się na języku SQL. Jednak OLEDB polega na COM. Ale ODBC istnieje już od wielu lat, więc istnieją mosty OLEDB-ODBC, aby temu zaradzić. Myślę, że kiedy M $ wymyśla OLEDB, jest duży obraz.

Scott Chu
źródło