Prima di ODBCEdit
L’introduzione del database relazionale basato su mainframe durante gli anni 70 ha portato ad una proliferazione di metodi di accesso ai dati. Generalmente questi sistemi operavano insieme ad un semplice processore di comandi che permetteva agli utenti di digitare comandi in stile inglese e ricevere l’output. Gli esempi più noti sono SQL di IBM e QUEL del progetto Ingres. Questi sistemi possono o non possono permettere ad altre applicazioni di accedere direttamente ai dati, e quelli che lo hanno fatto usano una grande varietà di metodologie. L’introduzione di SQL mirava a risolvere il problema della standardizzazione del linguaggio, anche se rimanevano sostanziali differenze nell’implementazione.
Siccome il linguaggio SQL aveva solo caratteristiche rudimentali di programmazione, gli utenti spesso volevano usare SQL all’interno di un programma scritto in un altro linguaggio, per esempio Fortran o C. Questo ha portato al concetto di Embedded SQL, che permetteva al codice SQL di essere incorporato all’interno di un altro linguaggio. Per esempio, un’istruzione SQL come SELECT * FROM city poteva essere inserita come testo nel codice sorgente C, e durante la compilazione sarebbe stata convertita in un formato personalizzato che chiamava direttamente una funzione all’interno di una libreria che avrebbe passato l’istruzione nel sistema SQL. I risultati restituiti dalle dichiarazioni sarebbero stati interpretati in formati di dati C come char * usando un codice di libreria simile.
C’erano diversi problemi con l’approccio Embedded SQL. Come le diverse varietà di SQL, gli Embedded SQL che li utilizzavano variavano ampiamente, non solo da piattaforma a piattaforma, ma anche tra i linguaggi su una piattaforma – un sistema che permetteva le chiamate a DB2 di IBM sarebbe stato molto diverso da uno che chiamava il loro SQL/DS. Un altro problema chiave del concetto di Embedded SQL era che il codice SQL poteva essere cambiato solo nel codice sorgente del programma, così che anche piccole modifiche alla query richiedevano un considerevole sforzo da parte del programmatore. Il mercato dell’SQL si riferiva a questo come SQL statico, contro l’SQL dinamico che poteva essere cambiato in qualsiasi momento, come le interfacce a riga di comando fornite con quasi tutti i sistemi SQL, o un’interfaccia di programmazione che lasciava l’SQL come testo semplice finché non veniva chiamato. I sistemi SQL dinamici divennero un obiettivo importante per i venditori di SQL durante gli anni ’80.
I vecchi database mainframe, e i più recenti sistemi basati su microcomputer, generalmente non avevano un processore di comando simile all’SQL tra l’utente e il motore del database. Invece, i dati erano accessibili direttamente dal programma – una libreria di programmazione nel caso di grandi sistemi mainframe, o un’interfaccia a linea di comando o un sistema di moduli interattivi nel caso di dBASE e applicazioni simili. I dati da dBASE non potevano generalmente essere accessibili direttamente da altri programmi in esecuzione sulla macchina. A quei programmi poteva essere dato un modo per accedere a questi dati, spesso attraverso librerie, ma non avrebbe funzionato con nessun altro motore di database, o anche con diversi database nello stesso motore. In effetti, tutti questi sistemi erano statici, il che presentava notevoli problemi.
Primi sforziEdit
Dalla metà degli anni ’80 il rapido miglioramento dei microcomputer, e specialmente l’introduzione dell’interfaccia grafica utente e dei programmi applicativi ricchi di dati come Lotus 1-2-3 portò ad un crescente interesse nell’uso dei personal computer come piattaforma client-side di scelta nel client-server computing. Secondo questo modello, i grandi mainframe e minicomputer sarebbero stati usati principalmente per fornire dati su reti locali a microcomputer che avrebbero interpretato, visualizzato e manipolato quei dati. Per far funzionare questo modello, uno standard di accesso ai dati era un requisito – nel campo dei mainframe era molto probabile che tutti i computer in un negozio fossero di un fornitore e i clienti fossero terminali di computer che parlavano direttamente con loro, ma nel campo dei microcomputer non c’era questa standardizzazione e qualsiasi cliente poteva accedere a qualsiasi server usando qualsiasi sistema di rete.
Dalla fine degli anni ’80 c’erano diversi sforzi in corso per fornire un livello di astrazione per questo scopo. Alcuni di questi erano legati ai mainframe, progettati per permettere ai programmi che giravano su quelle macchine di tradurre tra la varietà di SQL e fornire una singola interfaccia comune che poteva poi essere chiamata da altri programmi per mainframe o microcomputer. Queste soluzioni includevano la Distributed Relational Database Architecture (DRDA) di IBM e il Data Access Language di Apple Computer. Molto più comuni, comunque, erano i sistemi che giravano interamente sui microcomputer, includendo uno stack di protocollo completo che includeva qualsiasi supporto di rete o di traduzione di file richiesto.
Uno dei primi esempi di un tale sistema era DataLens di Lotus Development, inizialmente conosciuto come Blueprint. Blueprint, sviluppato per 1-2-3, supportava una varietà di fonti di dati, inclusi SQL/DS, DB2, FOCUS e una varietà di sistemi mainframe simili, così come sistemi per microcomputer come dBase e i primi sforzi di Microsoft/Ashton-Tate che si sarebbero poi sviluppati in Microsoft SQL Server. A differenza del successivo ODBC, Blueprint era un sistema puramente basato sul codice, senza nulla che si avvicinasse ad un linguaggio di comando come SQL. Invece, i programmatori usavano strutture di dati per memorizzare le informazioni della query, costruendo una query collegando molte di queste strutture insieme. Lotus si riferiva a queste strutture composte come alberi di query.
All’incirca nello stesso periodo, un team industriale che includeva membri di Sybase (Tom Haggin), Tandem Computers (Jim Gray & Rao Yendluri) e Microsoft (Kyle G) stava lavorando su un concetto di SQL dinamico standardizzato. Gran parte del sistema era basato sul sistema DB-Library di Sybase, con le sezioni specifiche di Sybase rimosse e diverse aggiunte per supportare altre piattaforme. DB-Library fu aiutato da uno spostamento a livello industriale dai sistemi di libreria che erano strettamente legati a un linguaggio specifico, ai sistemi di libreria che erano forniti dal sistema operativo e richiedevano che i linguaggi su quella piattaforma fossero conformi ai suoi standard. Questo significava che una singola libreria poteva essere usata con (potenzialmente) qualsiasi linguaggio di programmazione su una data piattaforma.
La prima bozza della Microsoft Data Access API fu pubblicata nell’aprile del 1989, circa nello stesso periodo in cui Lotus annunciò Blueprint. Nonostante il grande vantaggio di Blueprint – era in funzione quando MSDA era ancora un progetto cartaceo – Lotus alla fine si unì agli sforzi di MSDA quando divenne chiaro che SQL sarebbe diventato lo standard de facto dei database. Dopo un considerevole contributo dell’industria, nell’estate del 1989 lo standard divenne SQL Connectivity (SQLC).
SAG e CLIEdit
Nel 1988 diversi venditori, principalmente dalle comunità Unix e database, formarono il SQL Access Group (SAG) nel tentativo di produrre un singolo standard di base per il linguaggio SQL. Al primo incontro ci fu un considerevole dibattito se lo sforzo dovesse lavorare solo sul linguaggio SQL o tentare una standardizzazione più ampia che includesse anche un sistema dinamico di integrazione del linguaggio SQL, quello che chiamarono una Call Level Interface (CLI). Mentre partecipava alla riunione con una prima bozza di quello che allora era ancora conosciuto come MS Data Access, Kyle Geiger di Microsoft invitò Jeff Balboni e Larry Barnes della Digital Equipment Corporation (DEC) a partecipare anche alle riunioni di SQLC. SQLC era una potenziale soluzione alla richiesta di CLI, che era guidata da DEC.
La nuova “banda dei quattro” di SQLC, MS, Tandem, DEC e Sybase, portò una versione aggiornata di SQLC alla successiva riunione del SAG nel giugno 1990. Il SAG rispose aprendo lo sforzo standard a qualsiasi progetto concorrente, ma delle molte proposte, solo Oracle Corp aveva un sistema che presentava una seria competizione. Alla fine, SQLC vinse i voti e divenne la bozza dello standard, ma solo dopo che vaste porzioni dell’API furono rimosse – il documento standard fu tagliato da 120 pagine a 50 durante questo periodo. Fu anche durante questo periodo che il nome Call Level Interface fu formalmente adottato. Nel 1995 SQL/CLI divenne parte dello standard internazionale SQL, ISO/IEC 9075-3. Il SAG stesso fu preso dal gruppo X/Open nel 1996, e, col tempo, divenne parte del Common Application Environment di The Open Group.
MS continuò a lavorare con lo standard SQLC originale, mantenendo molte delle caratteristiche avanzate che furono rimosse dalla versione CLI. Queste includevano caratteristiche come i cursori a scorrimento e le query di informazioni sui metadati. I comandi nell’API furono divisi in gruppi; il gruppo Core era identico alla CLI, le estensioni di livello 1 erano comandi che sarebbero stati facili da implementare nei driver, mentre i comandi di livello 2 contenevano le caratteristiche più avanzate come i cursori. Una proposta di standard fu rilasciata nel dicembre 1991, e l’input dell’industria fu raccolto e lavorato nel sistema fino al 1992, con il risultato di un altro cambio di nome in ODBC.
JET e ODBCEdit
In questo periodo, Microsoft era nel mezzo dello sviluppo del suo sistema di database Jet. Jet combinava tre sottosistemi primari; un motore di database basato su ISAM (anch’esso chiamato Jet, confusamente), un’interfaccia basata su C che permetteva alle applicazioni di accedere a quei dati, e una selezione di librerie a collegamento dinamico (DLL) di driver che permettevano alla stessa interfaccia C di reindirizzare input e output ad altri database basati su ISAM, come Paradox e xBase. Jet permetteva di usare una serie di chiamate per accedere a comuni database per microcomputer in modo simile a Blueprint, poi rinominato DataLens. Tuttavia, Jet non usava SQL; come DataLens, l’interfaccia era in C e consisteva in strutture di dati e chiamate a funzioni.
Gli sforzi di standardizzazione del SAG presentarono un’opportunità per Microsoft di adattare il loro sistema Jet al nuovo standard CLI. Questo non solo avrebbe reso Windows una piattaforma primaria per lo sviluppo CLI, ma avrebbe anche permesso agli utenti di usare SQL per accedere sia a Jet che ad altri database. Quello che mancava era il parser SQL che potesse convertire quelle chiamate dalla loro forma testuale nell’interfaccia C usata in Jet. Per risolvere questo, MS ha collaborato con PageAhead Software per usare il loro processore di query esistente, SIMBA. SIMBA fu usato come parser sopra la libreria C di Jet, trasformando Jet in un database SQL. E poiché Jet poteva inoltrare quelle chiamate basate su C ad altri database, questo permetteva anche a SIMBA di interrogare altri sistemi. Microsoft incluse i driver per Excel per trasformare i suoi documenti di foglio di calcolo in tabelle di database accessibili in SQL.
Rilascio e sviluppo continuoModifica
ODBC 1.0 fu rilasciato nel settembre 1992. A quel tempo, c’era poco supporto diretto per i database SQL (rispetto a ISAM), e i primi driver erano noti per le scarse prestazioni. Parte di questo era inevitabile a causa del percorso che le chiamate prendevano attraverso lo stack basato su Jet; le chiamate ODBC ai database SQL erano prima convertite dal dialetto SQL di Simba Technologies al formato interno basato su C di Jet, poi passate a un driver per la conversione di nuovo in chiamate SQL per il database. Digital Equipment e Oracle hanno entrambi contrattato Simba Technologies per sviluppare driver anche per i loro database.
Nel frattempo, lo sforzo dello standard CLI si trascinò, e non fu fino al marzo 1995 che la versione definitiva fu finalizzata. A quel punto, Microsoft aveva già concesso a Visigenic Software una licenza di codice sorgente per sviluppare ODBC su piattaforme non Windows. Visigenic portò ODBC su un’ampia varietà di piattaforme Unix, dove ODBC divenne rapidamente lo standard de facto. La “vera” CLI è rara oggi. I due sistemi rimangono simili, e molte applicazioni possono essere portate da ODBC a CLI con pochi o nessun cambiamento.
Con il tempo, i fornitori di database hanno preso in consegna le interfacce dei driver e hanno fornito collegamenti diretti ai loro prodotti. Saltando le conversioni intermedie da e verso Jet o wrapper simili spesso si ottenevano prestazioni più elevate. Tuttavia, a quel punto Microsoft aveva cambiato l’attenzione sul concetto di OLE DB (recentemente ripristinato), che forniva un accesso diretto a una più ampia varietà di fonti di dati, dalle rubriche ai file di testo. Seguirono diversi nuovi sistemi che distolsero ulteriormente la loro attenzione da ODBC, inclusi ActiveX Data Objects (ADO) e ADO.net, che interagirono più o meno con ODBC nel corso della loro vita.
Come Microsoft distolse la sua attenzione dal lavorare direttamente su ODBC, il campo Unix lo stava abbracciando sempre più. Questo fu spinto da due cambiamenti all’interno del mercato, l’introduzione di interfacce utente grafiche (GUI) come GNOME che fornivano la necessità di accedere a queste fonti in forma non testuale, e l’emergere di sistemi di database open software come PostgreSQL e MySQL, inizialmente sotto Unix. La successiva adozione di ODBC da parte di Apple per l’utilizzo del pacchetto standard Unix-side iODBC Mac OS X 10.2 (Jaguar) (che OpenLink Software aveva fornito indipendentemente per Mac OS X 10.0 e anche Mac OS 9 dal 2001) ha ulteriormente cementato ODBC come standard per l’accesso ai dati multipiattaforma.
Sun Microsystems ha utilizzato il sistema ODBC come base per il proprio standard aperto, Java Database Connectivity (JDBC). In molti modi, JDBC può essere considerato una versione di ODBC per il linguaggio di programmazione Java invece di C. I bridge JDBC-to-ODBC permettono ai programmi basati su Java di accedere a fonti di dati attraverso driver ODBC su piattaforme che non hanno un driver JDBC nativo, sebbene questi siano ora relativamente rari. Inversamente, i bridge ODBC-to-JDBC permettono ai programmi basati su C di accedere a fonti di dati attraverso driver JDBC su piattaforme o da database che mancano di driver ODBC adatti.
ODBC oggiModifica
ODBC rimane in largo uso oggi, con driver disponibili per la maggior parte delle piattaforme e la maggior parte dei database. Non è raro trovare driver ODBC per motori di database che sono pensati per essere incorporati, come SQLite, come un modo per permettere agli strumenti esistenti di agire come front-end a questi motori per i test e il debug.
Tuttavia, l’ascesa del calcolo thin client che usa HTML come formato intermedio ha ridotto la necessità di ODBC. Molte piattaforme di sviluppo web contengono collegamenti diretti ai database di destinazione – MySQL è molto comune. In questi scenari, non c’è un accesso diretto lato client né sistemi software client multipli da supportare; tutto passa attraverso l’applicazione HTML fornita dal programmatore. La virtualizzazione che ODBC offre non è più un requisito forte, e lo sviluppo di ODBC non è più attivo come una volta. Ma quando ODBC non è più un forte requisito per la programmazione client-server, ora ODBC è più importante per l’accesso ai dati e la virtualizzazione dei dati dell’integrazione dei dati negli scenari di data analytic e data science. Questi nuovi requisiti si riflettono nelle nuove caratteristiche di ODBC 4.0 come i dati semi-strutturati e gerarchici, l’autenticazione web e il miglioramento delle prestazioni.
Storia della versioneModifica
Storia della versione:
- 1.0: rilasciato nel settembre 1992
- 2.0: c. 1994
- 2.5
- 3.0: c. 1995, John Goodson di Intersolv e Frank Pellow e Paul Cotton di IBM hanno fornito un contributo significativo a ODBC 3.0
- 3.5: c. 1997
- 3.8: c. 2009, con Windows 7
- 4.0: Sviluppo annunciato a giugno 2016 con la prima implementazione con SQL Server 2017 rilasciata a settembre 2017 e ulteriori driver desktop a fine 2018 specifiche finali su Github