Przed ODBCEdit
Wprowadzenie relacyjnej bazy danych opartej na mainframe w latach 70. doprowadziło do rozpowszechnienia się metod dostępu do danych. Generalnie systemy te działały razem z prostym procesorem poleceń, który pozwalał użytkownikom na wpisywanie poleceń w języku angielskim i otrzymywanie danych wyjściowych. Najbardziej znanymi przykładami są SQL z IBM i QUEL z projektu Ingres. Systemy te mogą, ale nie muszą pozwalać innym aplikacjom na bezpośredni dostęp do danych, a te, które to robiły, stosowały bardzo różne metodologie. Wprowadzenie języka SQL miało na celu rozwiązanie problemu standaryzacji języka, choć nadal istniały znaczne różnice w jego implementacji.
Ponieważ język SQL posiadał jedynie podstawowe funkcje programistyczne, użytkownicy często chcieli używać SQL w programie napisanym w innym języku, na przykład Fortranie lub C. Doprowadziło to do powstania koncepcji osadzonego SQL, która pozwalała na osadzenie kodu SQL w innym języku. Na przykład, instrukcja SQL taka jak SELECT * FROM city mogła być umieszczona jako tekst w kodzie źródłowym C, a podczas kompilacji została przekonwertowana na niestandardowy format, który bezpośrednio wywoływał funkcję w bibliotece, która przekazywała instrukcję do systemu SQL. Wyniki zwracane z instrukcji byłyby interpretowane z powrotem do formatów danych C, takich jak char * przy użyciu podobnego kodu biblioteki.
Istniało kilka problemów z podejściem Embedded SQL. Podobnie jak różne odmiany SQL, używane przez nie Embedded SQL bardzo się różniły, nie tylko między platformami, ale nawet między językami na jednej platformie – system, który pozwalał na wywołania do IBM DB2, wyglądałby zupełnie inaczej niż ten, który wywoływał do ich własnego SQL/DS. Innym kluczowym problemem koncepcji Embedded SQL było to, że kod SQL mógł być zmieniany tylko w kodzie źródłowym programu, tak więc nawet niewielkie zmiany w zapytaniu wymagały znacznego wysiłku programisty, aby je zmodyfikować. Rynek SQL określał to jako statyczny SQL, w przeciwieństwie do dynamicznego SQL, który mógł być zmieniany w dowolnym momencie, jak interfejsy wiersza poleceń, które były dostarczane z prawie wszystkimi systemami SQL, lub interfejs programistyczny, który pozostawiał SQL jako zwykły tekst, dopóki nie został wywołany. Dynamiczne systemy SQL stały się głównym przedmiotem zainteresowania dostawców SQL w latach 80-tych.
Starsze bazy danych mainframe i nowsze systemy mikrokomputerowe, które były na nich oparte, generalnie nie miały podobnego do SQL procesora poleceń pomiędzy użytkownikiem a motorem bazy danych. Zamiast tego, dostęp do danych był uzyskiwany bezpośrednio przez program – bibliotekę programistyczną w przypadku dużych systemów mainframe, lub interfejs wiersza poleceń lub system formularzy interaktywnych w przypadku dBASE i podobnych aplikacji. Dane z dBASE nie mogły być na ogół dostępne bezpośrednio dla innych programów działających na maszynie. Programy te mogły mieć dostęp do tych danych, często za pośrednictwem bibliotek, ale nie działałyby one z żadnym innym motorem bazy danych, a nawet z różnymi bazami danych w tym samym motorze. W efekcie, wszystkie takie systemy były statyczne, co stwarzało poważne problemy.
Wczesne wysiłkiEdit
W połowie lat 80. szybki rozwój mikrokomputerów, a zwłaszcza wprowadzenie graficznego interfejsu użytkownika i bogatych w dane programów użytkowych, takich jak Lotus 1-2-3, doprowadziły do wzrostu zainteresowania wykorzystaniem komputerów osobistych jako platformy z wyboru w obliczeniach klient-serwer. W tym modelu duże komputery mainframe i minikomputery byłyby używane głównie do dostarczania danych przez sieci lokalne do mikrokomputerów, które interpretowałyby, wyświetlały i manipulowały tymi danymi. Aby ten model mógł działać, wymagany był standard dostępu do danych – w dziedzinie mainframe było bardzo prawdopodobne, że wszystkie komputery w sklepie pochodziły od jednego producenta, a klienci byli terminalami komputerowymi rozmawiającymi bezpośrednio z nimi, ale w dziedzinie mikro nie było takiej standaryzacji i każdy klient mógł uzyskać dostęp do dowolnego serwera przy użyciu dowolnego systemu sieciowego.
Pod koniec lat 80. podjęto kilka wysiłków w celu zapewnienia warstwy abstrakcji do tego celu. Niektóre z nich były związane z komputerami mainframe i miały na celu umożliwienie programom działającym na tych maszynach tłumaczenie pomiędzy różnymi SQL-ami i dostarczenie jednego wspólnego interfejsu, który mógłby być następnie wywoływany przez inne programy mainframe lub mikrokomputerowe. Do takich rozwiązań należały Distributed Relational Database Architecture (DRDA) firmy IBM oraz Data Access Language firmy Apple Computer. Znacznie bardziej powszechne były jednak systemy działające w całości na mikrokomputerach, zawierające kompletny stos protokołów, który obejmował wszelkie wymagane sieci lub obsługę translacji plików.
Jednym z wczesnych przykładów takiego systemu był DataLens firmy Lotus Development, początkowo znany jako Blueprint. Blueprint, opracowany dla 1-2-3, obsługiwał wiele źródeł danych, w tym SQL/DS, DB2, FOCUS i wiele podobnych systemów mainframe, a także systemy mikrokomputerowe, takie jak dBase i wczesne wysiłki Microsoft/Ashton-Tate, które ostatecznie przekształciły się w Microsoft SQL Server. W przeciwieństwie do późniejszego ODBC, Blueprint był systemem opartym wyłącznie na kodzie, pozbawionym czegokolwiek, co przypominałoby język poleceń, taki jak SQL. Zamiast tego programiści używali struktur danych do przechowywania informacji o zapytaniach, konstruując zapytanie poprzez łączenie ze sobą wielu takich struktur. Lotus określał te złożone struktury mianem drzew zapytań.
Mniej więcej w tym samym czasie zespół branżowy, w skład którego wchodzili członkowie firm Sybase (Tom Haggin), Tandem Computers (Jim Gray & Rao Yendluri) i Microsoft (Kyle G), pracował nad ustandaryzowaną koncepcją dynamicznego SQL. Duża część systemu była oparta na systemie DB-Library firmy Sybase, z usuniętymi sekcjami specyficznymi dla Sybase i kilkoma dodatkami do obsługi innych platform. DB-Library był wspomagany przez ogólnobranżowe przejście od systemów bibliotecznych, które były ściśle związane z konkretnym językiem, do systemów bibliotecznych, które były dostarczane przez system operacyjny i wymagały, aby języki na tej platformie były zgodne z jego standardami. Oznaczało to, że pojedyncza biblioteka może być używana z (potencjalnie) każdym językiem programowania na danej platformie.
Pierwszy szkic Microsoft Data Access API został opublikowany w kwietniu 1989 roku, mniej więcej w tym samym czasie, co ogłoszenie Blueprint przez Lotusa. Pomimo dużej przewagi Blueprint – działał on, gdy MSDA było jeszcze projektem papierowym – Lotus ostatecznie dołączył do wysiłków MSDA, gdy stało się jasne, że SQL stanie się de facto standardem baz danych. Po znacznym wkładzie przemysłu, w lecie 1989 roku standardem stał się SQL Connectivity (SQLC).
SAG i CLIEdit
W 1988 roku kilku dostawców, głównie ze społeczności Unix i baz danych, utworzyło SQL Access Group (SAG) w celu stworzenia jednego podstawowego standardu dla języka SQL. Na pierwszym spotkaniu odbyła się poważna debata na temat tego, czy należy pracować wyłącznie nad samym językiem SQL, czy też podjąć próbę szerszej standaryzacji, która obejmowałaby również dynamiczny system osadzania języka SQL, co nazwano Call Level Interface (CLI). Uczestnicząc w spotkaniu z wczesną wersją tego, co wtedy było jeszcze znane jako MS Data Access, Kyle Geiger z Microsoftu zaprosił Jeffa Balboniego i Larry’ego Barnesa z Digital Equipment Corporation (DEC), aby również przyłączyli się do spotkań SQLC. SQLC stanowiło potencjalne rozwiązanie problemu CLI, który był prowadzony przez DEC.
Nowy „gang czworga” SQLC, MS, Tandem, DEC i Sybase, przyniósł uaktualnioną wersję SQLC na następne spotkanie SAG w czerwcu 1990 roku. SAG odpowiedziało otwarciem standardowej pracy dla każdego konkurencyjnego projektu, ale spośród wielu propozycji tylko Oracle Corp miało system, który stanowił poważną konkurencję. Ostatecznie SQLC wygrał w głosowaniu i stał się projektem standardu, ale dopiero po usunięciu dużych fragmentów API – dokument standardu został w tym czasie skrócony ze 120 stron do 50. Również w tym okresie formalnie przyjęto nazwę Call Level Interface. W 1995 roku SQL/CLI stał się częścią międzynarodowego standardu SQL, ISO/IEC 9075-3. Sam SAG został przejęty przez grupę X/Open w 1996 roku, a z czasem stał się częścią The Open Group’s Common Application Environment.
MS kontynuował pracę z oryginalnym standardem SQLC, zachowując wiele zaawansowanych funkcji, które zostały usunięte z wersji CLI. Należały do nich takie funkcje, jak przewijane kursory i zapytania o informacje metadanych. Polecenia w API zostały podzielone na grupy; grupa Core była identyczna jak w CLI, rozszerzenia poziomu 1 były poleceniami, które byłyby łatwe do zaimplementowania w sterownikach, natomiast polecenia poziomu 2 zawierały bardziej zaawansowane funkcje, takie jak kursory. Zaproponowany standard został wydany w grudniu 1991 roku, a wkład przemysłu został zebrany i wprowadzony do systemu w 1992 roku, co zaowocowało kolejną zmianą nazwy na ODBC.
JET i ODBCEdit
W tym czasie Microsoft był w trakcie opracowywania swojego systemu baz danych Jet. Jet łączył w sobie trzy podstawowe podsystemy: oparty na ISAM silnik bazy danych (również o mylącej nazwie Jet), oparty na języku C interfejs umożliwiający aplikacjom dostęp do tych danych oraz wybór sterowników bibliotek dynamicznych (DLL), które pozwalały temu samemu interfejsowi C przekierować dane wejściowe i wyjściowe do innych baz danych opartych na ISAM, takich jak Paradox i xBase. Jet pozwalał na użycie jednego zestawu wywołań do uzyskania dostępu do powszechnych mikrokomputerowych baz danych w sposób podobny do Blueprint, który wtedy zmienił nazwę na DataLens. Jet nie używał jednak języka SQL; podobnie jak DataLens, interfejs był w języku C i składał się ze struktur danych i wywołań funkcji.
Podejmowane przez SAG wysiłki standaryzacyjne stanowiły dla Microsoftu okazję do przystosowania systemu Jet do nowego standardu CLI. Dzięki temu Windows stałby się nie tylko główną platformą dla rozwoju CLI, ale także użytkownicy mogliby używać SQL do uzyskiwania dostępu zarówno do Jeta, jak i innych baz danych. Brakowało jednak parsera SQL, który mógłby przekształcić te wywołania z postaci tekstowej na interfejs C używany w systemie Jet. Aby rozwiązać ten problem, MS nawiązał współpracę z firmą PageAhead Software i wykorzystał ich istniejący procesor zapytań, SIMBA. SIMBA została użyta jako parser nad biblioteką C Jeta, przekształcając Jeta w bazę danych SQL. A ponieważ Jet mógł przekazywać te oparte na języku C wywołania do innych baz danych, pozwalało to także SIMBA na zadawanie zapytań innym systemom. Microsoft dołączył sterowniki dla Excela, aby przekształcić dokumenty arkusza kalkulacyjnego w tabele bazy danych dostępne w języku SQL.
Wydanie i dalszy rozwójEdit
ODBC 1.0 zostało wydane we wrześniu 1992 roku. W tamtym czasie istniało niewielkie bezpośrednie wsparcie dla baz danych SQL (w porównaniu z ISAM), a wczesne sterowniki charakteryzowały się niską wydajnością. Wywołania ODBC do baz SQL były najpierw konwertowane z dialektu SQL firmy Simba Technologies na wewnętrzny format Jeta, oparty na języku C, a następnie przekazywane do sterownika w celu konwersji z powrotem na wywołania SQL dla bazy danych. Firmy Digital Equipment i Oracle zleciły Simba Technologies opracowanie sterowników dla swoich baz danych.
W międzyczasie prace nad standardem CLI przeciągały się i dopiero w marcu 1995 r. ukończono jego ostateczną wersję. Do tego czasu Microsoft udzielił już firmie Visigenic Software licencji na kod źródłowy, umożliwiającej rozwój ODBC na platformach innych niż Windows. Visigenic przeportował ODBC na wiele różnych platform uniksowych, gdzie ODBC szybko stał się standardem de facto. „Prawdziwe” CLI jest dziś rzadkością. Oba systemy pozostają podobne, a wiele aplikacji można przenieść z ODBC na CLI z niewielkimi zmianami lub bez zmian.
Z czasem producenci baz danych przejęli interfejsy sterowników i udostępnili bezpośrednie łącza do swoich produktów. Pominięcie pośrednich konwersji do i z Jeta lub podobnych wrapperów często skutkowało wyższą wydajnością. Jednak do tego czasu Microsoft skupił się na swojej koncepcji OLE DB (niedawno przywróconej), która zapewniała bezpośredni dostęp do szerszej gamy źródeł danych, od książek adresowych po pliki tekstowe. Następnie pojawiło się kilka nowych systemów, które jeszcze bardziej odwróciły uwagę od ODBC, w tym ActiveX Data Objects (ADO) i ADO.net, które w mniejszym lub większym stopniu współdziałały z ODBC przez cały okres swojego istnienia.
Podczas gdy Microsoft odwracał swoją uwagę od bezpośredniej pracy nad ODBC, środowisko uniksowe w coraz większym stopniu je przyjmowało. Było to napędzane przez dwie zmiany na rynku, wprowadzenie graficznych interfejsów użytkownika (GUI), takich jak GNOME, które zapewniły potrzebę dostępu do tych źródeł w formie innej niż tekstowa, oraz pojawienie się systemów baz danych otwartego oprogramowania, takich jak PostgreSQL i MySQL, początkowo pod Unixem. Późniejsze przyjęcie ODBC przez firmę Apple w celu wykorzystania standardowego, unixowego pakietu iODBC Mac OS X 10.2 (Jaguar) (który firma OpenLink Software niezależnie dostarczała dla Mac OS X 10.0, a nawet Mac OS 9 od 2001 r.) jeszcze bardziej ugruntowało pozycję ODBC jako standardu międzyplatformowego dostępu do danych.
Sun Microsystems wykorzystał system ODBC jako podstawę dla własnego otwartego standardu, Java Database Connectivity (JDBC). Pod wieloma względami JDBC można uznać za wersję ODBC dla języka programowania Java zamiast C. Mosty JDBC-to-ODBC umożliwiają programom opartym na Javie dostęp do źródeł danych za pośrednictwem sterowników ODBC na platformach nieposiadających natywnego sterownika JDBC, chociaż obecnie są one stosunkowo rzadkie. I odwrotnie, mosty ODBC-to-JDBC pozwalają programom opartym na języku C na dostęp do źródeł danych poprzez sterowniki JDBC na platformach lub z baz danych pozbawionych odpowiednich sterowników ODBC.
ODBC dzisiajEdit
ODBC pozostaje dziś w szerokim użyciu, ze sterownikami dostępnymi dla większości platform i większości baz danych. Nierzadko można znaleźć sterowniki ODBC dla baz danych, które są przeznaczone do osadzania, jak SQLite, aby umożliwić istniejącym narzędziom działanie jako front-end do tych silników w celu testowania i debugowania.
Jednakże wzrost popularności cienkiego klienta, wykorzystującego HTML jako format pośredni, zmniejszył zapotrzebowanie na ODBC. Wiele platform tworzenia stron internetowych zawiera bezpośrednie łącza do docelowych baz danych – MySQL jest bardzo popularny. W takich scenariuszach nie ma bezpośredniego dostępu po stronie klienta ani konieczności obsługi wielu systemów oprogramowania klienckiego; wszystko odbywa się za pośrednictwem aplikacji HTML dostarczonej przez programistę. Wirtualizacja, którą oferuje ODBC, nie jest już silnym wymogiem, a rozwój ODBC nie jest już tak aktywny jak kiedyś. Ale kiedy ODBC nie jest już silnym wymogiem dla programowania klient-serwer, teraz ODBC jest ważniejsze dla dostępu do danych i wirtualizacji danych w integracji danych w scenariuszach analizy danych i nauki o danych. Te nowe wymagania są odzwierciedlone w nowych funkcjach ODBC 4.0, takich jak dane półstrukturalne i hierarchiczne, uwierzytelnianie sieciowe i poprawa wydajności.
Historia wersjiEdit
Historia wersji:
- 1.0: wydana we wrześniu 1992
- 2.0: c. 1994
- 2.5
- 3.0: c. 1995, John Goodson z Intersolv oraz Frank Pellow i Paul Cotton z IBM dostarczyli znaczący wkład w ODBC 3.0
- 3.5: c. 1997
- 3.8: c. 2009, z Windows 7
- 4.0: Rozwój ogłoszony czerwiec 2016 z pierwszą implementacją z SQL Server 2017 wydany Sep 2017 i dodatkowe sterowniki pulpitu późno 2018 ostateczna specyfikacja na Github
.