SQLJ es un nombre provisional para los esfuerzos por combinar Java y SQL . Fue un esfuerzo común que comenzó alrededor de 1997 por ingenieros de IBM , Oracle , Compaq , Informix , Sybase , Cloudscape y Sun Microsystems .
Consta de tres partes: 0, 1 y 2. La parte 0 describe la incrustación de sentencias SQL en programas Java. SQLJ parte 0 es la base de la parte 10 del estándar SQL:1999 , también conocido como SQL Object Language Bindings (SQL/OLB). [ 1 ] SQLJ partes 1 y 2 describen la posibilidad inversa de usar clases Java (rutinas y tipos) desde sentencias SQL. Las partes 1 y 2 son la base de la parte 13 del estándar SQL, SQL Routines and Types Using the Java Programming Language (SQL/JRT).
"SQLJ" se usa comúnmente para referirse solo a la parte 0 de SQLJ, generalmente cuando se contrasta con otros medios de incrustar SQL en Java, como JDBC .
Normas ANSI e ISO
- SQLJ parte 0: ANSI X3.135.10-1998, "Lenguaje de base de datos SQL—Parte 10: Enlaces de lenguaje de objetos (SQL/OLB)"
- SQLJ parte 1: ANSI NCITS 331.1-1999, "SQLJ—Parte 1: Rutinas SQL utilizando el lenguaje de programación Java"
- SQLJ parte 2: ANSI NCITS 331.2-2000, "SQLJ—Parte 2: Tipos SQL utilizando el lenguaje de programación Java"
La Parte 0 se actualizó para ser compatible con JDBC 2.0 y fue ratificada por la ISO en 2000. Las dos últimas partes se combinaron al ser presentadas a la ISO. La Parte 2 se reescribió sustancialmente para su presentación a la ISO, ya que la versión ANSI no era lo suficientemente formal para una especificación, sino que se asemejaba más al estilo de un manual de usuario . La versión combinada fue ratificada en 2002. [ 1 ]
- ISO/IEC 9075-10:2000, Tecnología de la información—Lenguajes de bases de datos—SQL—Parte 10: Enlaces de lenguajes de objetos (SQL/OLB)
- ISO/IEC 9075-13:2002, Tecnología de la información—Lenguajes de bases de datos—SQL—Parte 13: Rutinas y tipos SQL utilizando el lenguaje de programación Java (SQL/JRT) .
SQLJ parte 0
La especificación SQLJ parte 0 se originó en gran medida en Oracle, que también proporcionó la primera implementación de referencia. [ 1 ]
En lo que sigue, SQLJ es sinónimo de SQLJ parte 0.
Mientras que JDBC proporciona una API , SQLJ consiste en una extensión de lenguaje . Por lo tanto, los programas que contienen SQLJ deben pasar por un preprocesador (el traductor de SQLJ) antes de poder compilarse.
Ventajas
Algunas ventajas de SQLJ sobre JDBC incluyen:
- Los comandos SQLJ suelen ser más cortos que los programas JDBC equivalentes.
- La sintaxis SQL se puede verificar en tiempo de compilación. Los resultados de la consulta también se pueden verificar rigurosamente.
- El preprocesador puede generar SQL estático, que ofrece un mejor rendimiento que el SQL dinámico, ya que el plan de consulta se crea durante la compilación del programa, se almacena en la base de datos y se reutiliza en tiempo de ejecución. El SQL estático garantiza la estabilidad del plan de acceso. IBM DB2 admite el uso de SQL estático en programas SQLJ.
Desventajas
- SQLJ requiere un paso de preprocesamiento.
- Muchos entornos de desarrollo integrados (IDE) no son compatibles con SQLJ.
- SQLJ carece de soporte para la mayoría de los marcos de persistencia comunes, como Hibernate .
- Oracle 18c (12.2) ha dejado de dar soporte a SQLJ en la base de datos.
Ejemplos
Los siguientes ejemplos comparan la sintaxis de SQLJ con el uso de JDBC.
Véase también
Referencias
Lecturas adicionales
- Connie Tsui, Consideraciones sobre SQLJ para sus aplicaciones Java DB2 V8 , IBM developerworks, 13 de febrero de 2003
- Owen Cline, Desarrolle sus aplicaciones con SQLJ , IBM DeveloperWorks, 16 de diciembre de 2004
- Jason Price (2001). Programación Java con Oracle SQLJ . O'Reilly Media. ISBN 978-0-596-00087-5.
Enlaces externos
- IBM Redbook: DB2 para z/OS y OS/390: Preparado para Java
- Guía para desarrolladores de Oracle SQLJ
- Java (plataforma de software)
- API de bases de datos
- Acceso a datos SQL