Repaso de JDBC
JDBC drivers in the wild
Este artículo de la revista electrónica JavaWorld, escrito por Nitin Nanda, resume las características principales de cada tipo de driver JDBC. A pesar de ser un artículo del 2000, nos sirve para tener una visión general de los drivers.
Tipo 1: Bridge JDBC-ODBC
Este driver traduce todas las llamadas JDBC a ODBC y las envía al driver ODBC (ver figura).
Esto nos lleva a que el driver ODBC tenga que estar en la máquina cliente.
A favor: los drivers ODBC están en todas partes.
En contra: prestaciones, instalación ODBC en el cliente.
Tipo 2: API nativo /driver Java parcial
Convierte las llamadas JDBC a llamadas propietarias del Gestor relacional. Ver figura.
A favor: mejores prestaciones que el tipo 1.
En contra: la biblioteca del vendedor ha de estar en la máquina cliente -no utilizable en aplicaciones internet-. Peores prestaciones que tipo 3 y tipo 4.
Tipo 3: Protocolo de red/driver todo Java
Sigue una arquitectura en tres capas. Si la capa intermedia es Java, ésta puede utilizar un tipo 1 ó 2 para hablar con la base de datos.
A favor: no hace falta instalación en máquina cliente del driver nativo. Puede proveer cache, balanceo de cargas, etc.
En contra: la capa intermedia requiere código para la base de datos.
Tipo 4: Protocolo nativo/driver todo Java
Convierte las llamadas JDBC a nativas de manera que el cliente se pueda comunicar directamente con el servidor gestor (ver figura).
A favor: prestaciones, sin instalaciones nativas en el cliente. Se permite la carga dinámica de drivers.
En contra: driver diferente para cada base de datos.
Conclusiones del benchmarking
Este artículo concluye que:
1. El tipo 1 no debería de utilizarse.
2. El tipo 2 es OK para intranets, pero 3 y 4 siguen siendo mejores.
3. Tipo 3 OK cuando hay multitud de bases de datos.
4. Para el resto, tipo 4.
Este artículo de la revista electrónica JavaWorld, escrito por Nitin Nanda, resume las características principales de cada tipo de driver JDBC. A pesar de ser un artículo del 2000, nos sirve para tener una visión general de los drivers.
- Tipo 1: Bridge JDBC-ODBC
- Tipo 2: API nativo /driver Java parcial
- Tipo 3: Protocolo de red/driver todo Java
- Tipo 4: Protocolo nativo/driver todo Java
Tipo 1: Bridge JDBC-ODBC
Este driver traduce todas las llamadas JDBC a ODBC y las envía al driver ODBC (ver figura).
Esto nos lleva a que el driver ODBC tenga que estar en la máquina cliente.
A favor: los drivers ODBC están en todas partes.
En contra: prestaciones, instalación ODBC en el cliente.
Tipo 2: API nativo /driver Java parcial
Convierte las llamadas JDBC a llamadas propietarias del Gestor relacional. Ver figura.
A favor: mejores prestaciones que el tipo 1.
En contra: la biblioteca del vendedor ha de estar en la máquina cliente -no utilizable en aplicaciones internet-. Peores prestaciones que tipo 3 y tipo 4.
Tipo 3: Protocolo de red/driver todo Java
Sigue una arquitectura en tres capas. Si la capa intermedia es Java, ésta puede utilizar un tipo 1 ó 2 para hablar con la base de datos.
A favor: no hace falta instalación en máquina cliente del driver nativo. Puede proveer cache, balanceo de cargas, etc.
En contra: la capa intermedia requiere código para la base de datos.
Tipo 4: Protocolo nativo/driver todo Java
Convierte las llamadas JDBC a nativas de manera que el cliente se pueda comunicar directamente con el servidor gestor (ver figura).
A favor: prestaciones, sin instalaciones nativas en el cliente. Se permite la carga dinámica de drivers.
En contra: driver diferente para cada base de datos.
Conclusiones del benchmarking
Este artículo concluye que:
1. El tipo 1 no debería de utilizarse.
2. El tipo 2 es OK para intranets, pero 3 y 4 siguen siendo mejores.
3. Tipo 3 OK cuando hay multitud de bases de datos.
4. Para el resto, tipo 4.
Comments