Antes de ODBCEdit
La introducción de la base de datos relacional basada en el mainframe durante la década de 1970 condujo a una proliferación de métodos de acceso a los datos. Por lo general, estos sistemas funcionaban junto con un simple procesador de comandos que permitía a los usuarios teclear comandos similares a los del inglés y recibir la salida. Los ejemplos más conocidos son SQL de IBM y QUEL del proyecto Ingres. Estos sistemas pueden o no permitir que otras aplicaciones accedan directamente a los datos, y las que lo hacían utilizaban una gran variedad de metodologías. La introducción de SQL pretendía resolver el problema de la estandarización del lenguaje, aunque seguían existiendo diferencias sustanciales en su implementación.
Dado que el lenguaje SQL sólo tenía características de programación rudimentarias, los usuarios a menudo querían utilizar SQL dentro de un programa escrito en otro lenguaje, por ejemplo Fortran o C. Esto dio lugar al concepto de SQL embebido, que permitía incrustar el código SQL dentro de otro lenguaje. Por ejemplo, una sentencia SQL como SELECT * FROM city podía insertarse como texto dentro del código fuente de C, y durante la compilación se convertía en un formato personalizado que llamaba directamente a una función dentro de una biblioteca que pasaba la sentencia al sistema SQL. Los resultados devueltos por las sentencias se volverían a interpretar en formatos de datos de C como char * utilizando un código de biblioteca similar.
Hubo varios problemas con el enfoque de SQL incrustado. Al igual que las diferentes variedades de SQL, los Embedded SQLs que los utilizaban variaban mucho, no sólo de una plataforma a otra, sino incluso entre lenguajes de una misma plataforma – un sistema que permitía llamadas a DB2 de IBM se vería muy diferente de uno que llamara a su propio SQL/DS. Otro problema clave del concepto de SQL incrustado era que el código SQL sólo podía cambiarse en el código fuente del programa, por lo que incluso los pequeños cambios en la consulta requerían un esfuerzo considerable del programador para modificarlos. El mercado de SQL se refería a esto como SQL estático, frente al SQL dinámico, que podía cambiarse en cualquier momento, como las interfaces de línea de comandos que venían con casi todos los sistemas SQL, o una interfaz de programación que dejaba el SQL como texto sin formato hasta que era llamado. Los sistemas SQL dinámicos se convirtieron en el principal objetivo de los proveedores de SQL durante la década de 1980.
Las antiguas bases de datos de mainframe, y los nuevos sistemas basados en microordenadores que se basaban en ellas, no solían tener un procesador de comandos similar a SQL entre el usuario y el motor de la base de datos. En su lugar, se accedía a los datos directamente a través del programa – una biblioteca de programación en el caso de los grandes sistemas mainframe, o una interfaz de línea de comandos o un sistema de formularios interactivos en el caso de dBASE y aplicaciones similares. Generalmente, los datos de dBASE no podían ser accedidos directamente por otros programas que se ejecutaban en la máquina. A esos programas se les podía dar una forma de acceder a estos datos, a menudo a través de bibliotecas, pero no funcionaba con ningún otro motor de base de datos, o incluso con diferentes bases de datos en el mismo motor. En efecto, todos estos sistemas eran estáticos, lo que presentaba considerables problemas.
Esfuerzos inicialesEditar
A mediados de la década de 1980, la rápida mejora de los microordenadores y, especialmente, la introducción de la interfaz gráfica de usuario y de programas de aplicación ricos en datos, como Lotus 1-2-3, condujeron a un creciente interés en el uso de los ordenadores personales como plataforma del lado del cliente elegida en la informática cliente-servidor. Según este modelo, los grandes ordenadores centrales y los miniordenadores se utilizarían principalmente para suministrar datos a través de las redes de área local a los microordenadores que interpretarían, mostrarían y manipularían esos datos. Para que este modelo funcionara, era necesario que existiera un estándar de acceso a los datos: en el ámbito de los mainframes era muy probable que todos los ordenadores de un taller fueran de un mismo proveedor y los clientes fueran terminales informáticos que se comunicaran directamente con ellos, pero en el ámbito de los microordenadores no existía tal estandarización y cualquier cliente podía acceder a cualquier servidor utilizando cualquier sistema de red.
A finales de la década de 1980 había varios esfuerzos en marcha para proporcionar una capa de abstracción con este fin. Algunos de ellos estaban relacionados con los mainframes, diseñados para permitir que los programas que se ejecutaban en esas máquinas tradujeran entre la variedad de SQL y proporcionaran una única interfaz común que pudiera ser llamada por otros programas de mainframe o microordenadores. Entre estas soluciones se encuentran la arquitectura de bases de datos relacionales distribuidas (DRDA) de IBM y el lenguaje de acceso a datos de Apple Computer. Sin embargo, son mucho más comunes los sistemas que se ejecutan íntegramente en microordenadores, incluyendo una pila de protocolos completa que incluye cualquier soporte de red o de traducción de archivos necesario.
Uno de los primeros ejemplos de este tipo de sistemas fue DataLens de Lotus Development, conocido inicialmente como Blueprint. Blueprint, desarrollado para 1-2-3, soportaba una gran variedad de fuentes de datos, incluyendo SQL/DS, DB2, FOCUS y una variedad de sistemas mainframe similares, así como sistemas de microordenadores como dBase y los primeros esfuerzos de Microsoft/Ashton-Tate que acabarían convirtiéndose en Microsoft SQL Server. A diferencia del posterior ODBC, Blueprint era un sistema puramente basado en código, sin nada parecido a un lenguaje de comandos como SQL. En su lugar, los programadores utilizaban estructuras de datos para almacenar la información de la consulta, construyendo una consulta mediante la vinculación de muchas de estas estructuras. Lotus se refería a estas estructuras compuestas como árboles de consulta.
Alrededor de la misma época, un equipo de la industria que incluía miembros de Sybase (Tom Haggin), Tandem Computers (Jim Gray & Rao Yendluri) y Microsoft (Kyle G) estaban trabajando en un concepto de SQL dinámico estandarizado. Gran parte del sistema se basó en el sistema DB-Library de Sybase, con las secciones específicas de Sybase eliminadas y varias adiciones para soportar otras plataformas. DB-Library se vio favorecido por un cambio en toda la industria, que pasó de sistemas de bibliotecas estrechamente vinculados a un lenguaje específico a sistemas de bibliotecas proporcionados por el sistema operativo y que requerían que los lenguajes de esa plataforma se ajustaran a sus estándares. Esto significaba que una única biblioteca podía utilizarse con (potencialmente) cualquier lenguaje de programación en una plataforma determinada.
El primer borrador de la API de acceso a datos de Microsoft se publicó en abril de 1989, más o menos al mismo tiempo que el anuncio de Blueprint por parte de Lotus. A pesar de la gran ventaja de Blueprint -estaba en marcha cuando MSDA era todavía un proyecto en papel- Lotus acabó uniéndose a los esfuerzos de MSDA cuando quedó claro que SQL se convertiría en el estándar de facto de las bases de datos. Tras una considerable aportación de la industria, en el verano de 1989 el estándar se convirtió en SQL Connectivity (SQLC).
SAG y CLIEdit
En 1988 varios proveedores, en su mayoría de las comunidades de Unix y de bases de datos, formaron el SQL Access Group (SAG) en un esfuerzo por producir un único estándar básico para el lenguaje SQL. En la primera reunión hubo un debate considerable sobre si el esfuerzo debía trabajar únicamente en el lenguaje SQL en sí, o intentar una estandarización más amplia que incluyera también un sistema dinámico de inserción del lenguaje SQL, lo que llamaron una Interfaz de Nivel de Llamada (CLI). Mientras asistía a la reunión con un primer borrador de lo que entonces todavía se conocía como MS Data Access, Kyle Geiger de Microsoft invitó a Jeff Balboni y Larry Barnes de Digital Equipment Corporation (DEC) a unirse también a las reuniones de SQLC. SQLC era una solución potencial a la petición de la CLI, que estaba siendo liderada por DEC.
La nueva «banda de los cuatro» de SQLC, MS, Tandem, DEC y Sybase, llevó una versión actualizada de SQLC a la siguiente reunión del SAG en junio de 1990. El SAG respondió abriendo el esfuerzo del estándar a cualquier diseño competidor, pero de las muchas propuestas, sólo Oracle Corp tenía un sistema que presentaba una competencia seria. Al final, SQLC ganó las votaciones y se convirtió en el borrador de la norma, pero sólo después de que se eliminaran grandes partes de la API: el documento de la norma se recortó de 120 páginas a 50 durante este tiempo. También fue durante este periodo cuando se adoptó formalmente el nombre de Call Level Interface. En 1995, SQL/CLI pasó a formar parte de la norma internacional SQL, ISO/IEC 9075-3. El propio SAG fue asumido por el grupo X/Open en 1996 y, con el tiempo, pasó a formar parte del Entorno de Aplicación Común de The Open Group.
MS continuó trabajando con el estándar SQLC original, conservando muchas de las características avanzadas que fueron eliminadas de la versión CLI. Entre ellas se encontraban características como los cursores desplazables y las consultas de información de metadatos. Los comandos de la API se dividieron en grupos: el grupo principal era idéntico al de la CLI, las extensiones de nivel 1 eran comandos fáciles de implementar en los controladores, mientras que los comandos de nivel 2 contenían las funciones más avanzadas, como los cursores. En diciembre de 1991 se publicó una propuesta de estándar y se recogieron las aportaciones de la industria, que se incorporaron al sistema a lo largo de 1992, lo que dio lugar a un nuevo cambio de nombre a ODBC.
JET y ODBCEdit
Durante esta época, Microsoft se encontraba en pleno desarrollo de su sistema de base de datos Jet. Jet combinaba tres subsistemas principales; un motor de base de datos basado en ISAM (también llamado Jet, confusamente), una interfaz basada en C que permitía a las aplicaciones acceder a esos datos, y una selección de librerías de enlace dinámico (DLL) de controladores que permitían a la misma interfaz C redirigir la entrada y salida a otras bases de datos basadas en ISAM, como Paradox y xBase. Jet permitía utilizar un conjunto de llamadas para acceder a las bases de datos comunes de los microordenadores de forma similar a Blueprint, por entonces rebautizado como DataLens. Sin embargo, Jet no utilizaba SQL; al igual que DataLens, la interfaz estaba en C y consistía en estructuras de datos y llamadas a funciones.
Los esfuerzos de estandarización del SAG presentaron una oportunidad para que Microsoft adaptara su sistema Jet al nuevo estándar CLI. Esto no sólo convertiría a Windows en una plataforma principal para el desarrollo de CLI, sino que también permitiría a los usuarios utilizar SQL para acceder tanto a Jet como a otras bases de datos. Lo que faltaba era el analizador SQL que pudiera convertir esas llamadas desde su forma de texto a la interfaz C utilizada en Jet. Para resolver esto, MS se asoció con PageAhead Software para utilizar su procesador de consultas existente, SIMBA. SIMBA se utilizó como parser por encima de la biblioteca C de Jet, convirtiendo a Jet en una base de datos SQL. Y como Jet podía reenviar esas llamadas basadas en C a otras bases de datos, esto también permitía a SIMBA consultar otros sistemas. Microsoft incluyó controladores para que Excel convirtiera sus documentos de hoja de cálculo en tablas de base de datos accesibles por SQL.
Lanzamiento y desarrollo continuado
ODBC 1.0 fue lanzado en septiembre de 1992. En aquel momento, había poco soporte directo para las bases de datos SQL (frente a ISAM), y los primeros controladores destacaban por su bajo rendimiento. Parte de esto era inevitable debido a la ruta que seguían las llamadas a través de la pila basada en Jet; las llamadas ODBC a bases de datos SQL se convertían primero del dialecto SQL de Simba Technologies al formato interno basado en C de Jet, y luego se pasaban a un controlador para convertirlas de nuevo en llamadas SQL para la base de datos. Digital Equipment y Oracle también contrataron a Simba Technologies para desarrollar controladores para sus bases de datos.
Mientras tanto, el esfuerzo del estándar CLI se alargó, y no fue hasta marzo de 1995 cuando se finalizó la versión definitiva. Para entonces, Microsoft ya había concedido a Visigenic Software una licencia de código fuente para desarrollar ODBC en plataformas no Windows. Visigenic portó ODBC a una amplia variedad de plataformas Unix, donde ODBC se convirtió rápidamente en el estándar de facto. El CLI «real» es raro hoy en día. Los dos sistemas siguen siendo similares, y muchas aplicaciones pueden ser portadas de ODBC a CLI con pocos o ningún cambio.
Con el tiempo, los proveedores de bases de datos se hicieron cargo de las interfaces de los controladores y proporcionaron enlaces directos a sus productos. El hecho de omitir las conversiones intermedias hacia y desde Jet o envoltorios similares a menudo daba lugar a un mayor rendimiento. Sin embargo, para entonces Microsoft había cambiado el enfoque hacia su concepto OLE DB (recientemente restablecido), que proporcionaba acceso directo a una mayor variedad de fuentes de datos, desde libretas de direcciones hasta archivos de texto. Le siguieron varios sistemas nuevos que desviaron aún más su atención de ODBC, incluyendo ActiveX Data Objects (ADO) y ADO.net, que interactuaron más o menos con ODBC a lo largo de su vida.
Mientras Microsoft desviaba su atención de trabajar directamente en ODBC, el campo de Unix lo adoptaba cada vez más. Esto fue impulsado por dos cambios dentro del mercado, la introducción de interfaces gráficas de usuario (GUI) como GNOME que proporcionó la necesidad de acceder a estas fuentes en forma no textual, y la aparición de sistemas de bases de datos de software abierto como PostgreSQL y MySQL, inicialmente bajo Unix. La posterior adopción de ODBC por parte de Apple para utilizar el paquete estándar iODBC del lado de Unix Mac OS X 10.2 (Jaguar) (que OpenLink Software había estado proporcionando de forma independiente para Mac OS X 10.0 e incluso Mac OS 9 desde 2001) consolidó aún más ODBC como el estándar para el acceso a datos entre plataformas.
Sun Microsystems utilizó el sistema ODBC como base para su propio estándar abierto, Java Database Connectivity (JDBC). En la mayoría de los sentidos, JDBC puede considerarse una versión de ODBC para el lenguaje de programación Java en lugar de C. Los puentes JDBC-to-ODBC permiten a los programas basados en Java acceder a fuentes de datos a través de controladores ODBC en plataformas que carecen de un controlador JDBC nativo, aunque ahora son relativamente raros. A la inversa, los puentes ODBC a JDBC permiten a los programas basados en C acceder a fuentes de datos a través de controladores JDBC en plataformas o bases de datos que carecen de controladores ODBC adecuados.
ODBC hoy en díaEditar
ODBC sigue siendo muy utilizado hoy en día, con controladores disponibles para la mayoría de las plataformas y la mayoría de las bases de datos. No es infrecuente encontrar controladores ODBC para motores de bases de datos que están destinados a ser incrustados, como SQLite, como una forma de permitir que las herramientas existentes actúen como front-ends de estos motores para las pruebas y la depuración.
Sin embargo, el aumento de la informática de cliente ligero que utiliza HTML como formato intermedio ha reducido la necesidad de ODBC. Muchas plataformas de desarrollo web contienen enlaces directos a las bases de datos de destino, siendo MySQL muy común. En estos escenarios, no hay acceso directo del lado del cliente ni múltiples sistemas de software de cliente que soportar; todo pasa por la aplicación HTML suministrada por el programador. La virtualización que ofrece ODBC ya no es un requisito importante, y el desarrollo de ODBC ya no es tan activo como antes. Pero cuando ODBC ya no es un requisito fuerte para la programación cliente-servidor, ahora es ODBC más importante para el acceso a los datos y la virtualización de la integración de datos en escenarios de analítica y ciencia de datos. Estos nuevos requisitos se reflejan en las nuevas características de ODBC 4.0, como los datos semiestructurados y jerárquicos, la autenticación web y la mejora del rendimiento.
Historia de versionesEditar
Historia de versiones:
- 1.0: lanzada en septiembre de 1992
- 2.0: c. 1994
- 2.5
- 3.0: c. 1995, John Goodson de Intersolv y Frank Pellow y Paul Cotton de IBM proporcionaron importantes aportaciones a ODBC 3.0
- 3.5: c. 1997
- 3.8: c. 2009, con Windows 7
- 4.0: Desarrollo anunciado en junio de 2016 con la primera implementación con SQL Server 2017 lanzada en septiembre de 2017 y controladores de escritorio adicionales a finales de 2018, especificación final en Github
.