![Bibliografía ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object], ](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Tendances
Tendances (19)
Similaire à Jdbc
Similaire à Jdbc (20)
Dernier
Dernier (20)
Jdbc
- 1. JDBC Java Database Connectivity
- 6. Proceso de trabajo con JDBC Aplicación JDBC Driver A Connection Statement Gestor de drivers Driver B ResultSet getConnection createStatement executeQuery
- 12. Tipos de drivers (III) Driver ODBC
- 16. Proceso de trabajo con JDBC Aplicación JDBC Driver A Connection Statement Gestor de drivers Driver B ResultSet getConnection createStatement executeQuery
- 23. Ejemplo de código de conexión a Oracle try { Class.forName("oracle.jdbc.driver.OracleDriver"); } catch (ClassNotFoundException e) { System.err.println("No se ha podido cargar el driver de la BD"); } ... Connection con = null ; try { String url = "jdbc:oracle:thin:@localhost:1521:PBD"; con = DriverManager.getConnection(url, "PBD", "pbdpbd"); ... Trabajo con la conexión } catch (SQLException e) { e.printStackTrace(); } finally { try { if (con != null ) con.close(); } catch (SQLException e2) { e2.printStackTrace(); } }
- 30. Ejemplo de código para Oracle // Carga del driver (Class.forName ... Connection con = null ; try { String url = "jdbc:oracle:thin:@localhost:1521:PBD"; con = DriverManager.getConnection(url, "PBD", "pbdpbd"); Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery(“SELECT a, b, c FROM Table2"); ... Procesamiento del resultado rs.close(); stmt.close(); } catch (SQLException e) { e.printStackTrace(); } finally { try { if (con != null ) con.close(); } catch (SQLException e2) { e2.printStackTrace(); } } OJO QUE NO ACABE EN ;
- 37. Tipos de datos y get<Tipo>
- 38. Ejemplo completo try { Class.forName("oracle.jdbc.driver.OracleDriver"); } catch (ClassNotFoundException e) { System.err.println("No se ha podido cargar el driver de la BD"); } Connection con = null ; try { String url = "jdbc:oracle:thin:@localhost:1521:PBD"; con = DriverManager.getConnection(url, "PBD", "pbdpbd"); Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM Table1"); while (rs.next()) { int i = rs.getInt("a"); // rs.getInt(1) String s = rs.getString("b"); // rs.getString(2) java.sql.Date f = rs.getDate("c"); // rs.getDate (3) System.out.println(“FILA = " + i + " " + s + " " + f); } try { Class.forName("oracle.jdbc.driver.OracleDriver"); } catch (ClassNotFoundException e) { System.err.println("No se ha podido cargar el driver de la BD"); } Connection con = null ; try { String url = "jdbc:oracle:thin:@localhost:1521:PBD"; con = DriverManager.getConnection(url, "PBD", "pbdpbd"); Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM Table1"); while (rs.next()) { int i = rs.getInt("a"); // rs.getInt(1) String s = rs.getString("b"); // rs.getString(2) java.sql.Date f = rs.getDate("c"); // rs.getDate (3) System.out.println(“FILA = " + i + " " + s + " " + f); } Carga del driver try { Class.forName("oracle.jdbc.driver.OracleDriver"); } catch (ClassNotFoundException e) { System.err.println("No se ha podido cargar el driver de la BD"); } Connection con = null ; try { String url = "jdbc:oracle:thin:@localhost:1521:PBD"; con = DriverManager.getConnection(url, "PBD", "pbdpbd"); Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM Table1"); while (rs.next()) { int i = rs.getInt("a"); // rs.getInt(1) String s = rs.getString("b"); // rs.getString(2) java.sql.Date f = rs.getDate("c"); // rs.getDate (3) System.out.println(“FILA = " + i + " " + s + " " + f); } Conexión try { Class.forName("oracle.jdbc.driver.OracleDriver"); } catch (ClassNotFoundException e) { System.err.println("No se ha podido cargar el driver de la BD"); } Connection con = null ; try { String url = "jdbc:oracle:thin:@localhost:1521:PBD"; con = DriverManager.getConnection(url, "PBD", "pbdpbd"); Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM Table1"); while (rs.next()) { int i = rs.getInt("a"); // rs.getInt(1) String s = rs.getString("b"); // rs.getString(2) java.sql.Date f = rs.getDate("c"); // rs.getDate (3) System.out.println(“FILA = " + i + " " + s + " " + f); } Consulta try { Class.forName("oracle.jdbc.driver.OracleDriver"); } catch (ClassNotFoundException e) { System.err.println("No se ha podido cargar el driver de la BD"); } Connection con = null ; try { String url = "jdbc:oracle:thin:@localhost:1521:PBD"; con = DriverManager.getConnection(url, "PBD", "pbdpbd"); Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM Table1"); while (rs.next()) { int i = rs.getInt("a"); // rs.getInt(1) String s = rs.getString("b"); // rs.getString(2) java.sql.Date f = rs.getDate("c"); // rs.getDate (3) System.out.println(“FILA = " + i + " " + s + " " + f); } Procesar resultado
- 39. Ejemplo completo (II) ... rs.close(); stmt.close(); } catch (SQLException e) { e.printStackTrace(); } finally { try { if (con != null ) con.close(); } catch (SQLException e) { e.printStackTrace(); } } ... rs.close(); stmt.close(); } catch (SQLException e) { e.printStackTrace(); } finally { try { if (con != null ) con.close(); } catch (SQLException e2) { e2.printStackTrace(); } } Cerrar TODO
- 40. Ejemplo de prácticas package sol; import bd.AbstractDBManager; import java.sql.*; import model.*; public class GestorBD extends AbstractDBManager { // Registro del driver apropiado para la BD a utilizar static { try { Class.forName("oracle.jdbc.driver.OracleDriver"); } catch (ClassNotFoundException e) { System.out.println("No puedo cargar el driver JDBC de la BD"); } } public Articulo getArticulo(String codigo) { } }
- 41. public Articulo getArticulo(String codigo) { Articulo articulo = null ; Connection con = null ; try { con = DriverManager.getConnection ("jdbc:oracle:thin:@localhost:1521:pbd", "prbd", "prbdprbd"); Statement stm = con.createStatement (); String sql = " SELECT nombre, PVP FROM Articulo WHERE codigo =' " +codigo+ " ' "; ResultSet res = stm.executeQuery(sql); if ( res.next() ) { articulo = new Articulo(codigo, res.getString("nombre") , res.getDouble("PVP") ); } res.close(); stm.close(); } catch (SQLException e) { e.printStackTrace(); } finally { if (con != null ) try { con.close(); } catch (SQLException ex) { ex.printStackTrace(); } } return articulo; }
- 46. Ejemplo try { Class.forName("oracle.jdbc.driver.OracleDriver"); } catch (ClassNotFoundException e) { System.err.println("No se ha podido cargar el driver de la BD"); } Connection con = null ; try { String url = "jdbc:oracle:thin:@localhost:1521:PBD"; con = DriverManager.getConnection(url, "PBD", "pbdpbd"); float sueldos [] = {1500, 2000, 1205.75f}; String nombres [] = {"Juan","Ana","Maria"}; PreparedStatement ps = con.prepareStatement("UPDATE table SET sueldo=? WHERE nombre=?"); for ( int i=0;i<sueldos.length;i++) { ps.setFloat(1,sueldos[i]); ps.setString(2,nombres[i]); ps.executeUpdate(); } ps.close();
- 47. Ejemplo (II) } catch (SQLException e) { e.printStackTrace(); } finally { try { if (con != null ) con.close(); } catch (SQLException e2) { e2.printStackTrace(); } }
- 56. Ejemplo ... Carga del driver ... String URL = "jdbc:oracle:thin:@localhost:1521:PBD"; Connection con = null ; try { con = DriverManager.getConnection(URL, "PBD", "pbdpbd"); con.setAutoCommit( false ); float sueldos [] = {1500, 2000, 1205.75f}; String nombres [] = {"Juan","Ana","Maria"}; PreparedStatement ps =con.prepareStatement("UPDATE table SET sueldo=?"+ "WHERE nombre=?"); for ( int i=0;i<sueldos.length;i++) { ps.setFloat(1,sueldos[i]); ps.setString(2,nombres[i]); ps.executeUpdate(); } ps.close(); con.commit();
- 57. Ejemplo (II) } catch (SQLException e) { e.printStackTrace(); try { if (con != null ) con.rollback(); } catch (SQLException e2) { e2.printStackTrace(); } } finally { try { if (con != null ) con.close(); } catch (SQLException e2) { e2.printStackTrace(); } }
- 67. Pool de Conexiones Aplicación DriverManager new Connection( con.close() Pool de Conexiones getConnection( getConnection(
- 78. } finally { try { if (presentacion != null ) presentacion.close(); } catch (SQLException e) { e.printStackTrace(); } }
Notes de l'éditeur
- En realidad JDBC es un nombre comercial por si mismo pero comunmente se conoce por Java Database Connectivity
- JDBC: Practical Guide for Java Programmers. Gregory Speegle. Morgan Kaufmann, 1st Ed (nov, 2001). ISBN: 1558607366. Malo JDBC API Tutorial and Reference, Third Edition . Maydene Fisher et al. Addison-Wesley Pub Co; 3rd edition (June 11, 2003). ISBN: 0321173848 Guia oficial de sun Java Programming with Oracle JDBC. Donald Bales. O'Reilly (January 2002). ISBN: 0-596-00088-X Bueno. Muchos detalles sobre Oracle. Saca las castañas del fuego en muchas ocasiones. Principles of DB Systems with Internet and Java . G. Riccardi. Addison Wesley 2001. ISBN: 02-0161-247-X Java Oracle Database Development. David J. Gallardo. Prentice Hall PTR (2003). ISBN: 0-13-046218-7 Me gusta. Muy completo. Ubre muchos temas. Un buen libro de programación de BD y no sólo de JDBC JDBC: Practical Guide for Java Programmers. Gregory Speegle. Morgan Kaufmann, 1st Ed (nov, 2001). ISBN: 1558607366. Database Programming with JDBC and Java, 2 nd Edition . George Reese. O'Reilly, 2000. ISBN: 1565926161 Java Database best Practices. George Reese, O’Reilly, 2003. ISBN: 0-596-00522-9 PARA programadores expertos. Trucos consejos sobre como hacer bien y más eficientemente las cosas JDBC™ Guide: Getting Started . Copyright © 1996, 1997, Sun Microsystems, Inc. Documentación sobre JDBC . http://java.sun.com/j2se/1.4.2/docs/guide/jdbc/index.html. PUNTO DE ARRANQUE Oracle9 i JDBC Developer’s Guide and Reference . Copyright © 1999, 2001 Oracle Corporation. COMPLICADA Y MUY DE DETALLE en relación solo con Oracle
- Razonar xq son interfaces y no clases concretas Ideas ya presentadas en el tema de Panorámica. Incidir en que es una capa entre aplicación y SGBDs Puntualizar: aisla de los detalles de un SBD concreto. Por ejemplo el tema de los comodines lo estandariza (es el % aunque en Access sea el *). Pero hay ciertas cosas que no están bien estandarizadas. Por ejemplo las funciones (son muy dependientes de el SGBD, no igual en Oracle que en Access). Además hay ciertas cosas que no están permitidas por el SGBD pr lo que simplemente no las hace. El metaData informa de si el SGBD soporta o no ciertas características.
- Decir que la petición de conexión se hace al driver pero que para no ligar la aplicación con un driver concreto (para no tener que recompilar si se cambia luego el SGBD concreto) se hace la petición a un intermediario que elige el driver adecuado y nos devuelve una conexión del tipo adecuado.
- Repasar los conceptos de conexión-instrucción-cursor del tema de panorámica
- Repasar de nuevo el q son interfaces. Verlos en el javadoc: decir que hay muy pocas clases concretas y que lo demás (los interfaces) es el resultado del proceso de abstracción de los de sun (los que desarrollaron JDBC) que vieron que elementos había en un API de conxión a BDs Mostrar la lista de drivers (ACTUALIZARLA) http://developers.sun.com/product/jdbc/drivers
- Los drivers que tiene Orace son de tpo 2 (el OCI) y de tipo 4 (el thin) Para uso con proc almac convene usar el OCI (es más rápido) En el caso de tipo 3: Oracle tiene una cosa llamada ConnectionManaget que actúa como ese middleware (ver Java Programming with Oracle JDBC cap 2 y sec 3.4, 3.4.1)
- En la página de Sun http://developers.sun.com/product/jdbc/drivers no se listan drivers de tipo 3.
- Decir que aunque nos referiramos al conjunto de clases que implementan los interfaces JDBC como driver ODBC hay entre esos interface uno que se llama Driver y cuya responsabilidad es dar conexiones Vover a decir que no se usa la clase concreta de driver, xq si lo hacemos perdemos la posibilidad de reutilizar el código con otra BD Si mi código empieza { OracleDriver driver = new OracleDriver(); Connection con = driver.connect(...); Si luego quiero usar el JdbcOdbcDriver, debo entrar en el código, cambiar y luego recompilar.
- Decir que la petición de conexión se hace al driver pero que para no ligar la aplicación con un driver concreto (para no tener que recompilar si se cambia luego el SGBD concreto) se hace la petición a un intermediario que elige el driver adecuado y nos devuelve una conexión del tipo adecuado.
- Hemos dicho que el Driverman guarda una lista de los drivers disponibles Como se forma esa lista … Si se desea introducir un nuevo driver después de que el DriverManager se halla inicializado se utilizará el método forname de la clase Class este método carga ña clase y la clase al cargarse se autoregistra
- Otras URL para otros drivers de Oracle (ver Java Programming with Oracle JDBC cap 2): Para OCI en Oracle 8: oci8 ... jdbc:oracle:oci8@<nombre tns> Para OCI en Oracle 9: oci ... jdbc:oracle:oci@<nombre tns> Para el driver interno de Oracle: kprb ... ??? Con los OCI sólo se puede usar lo de tns_name y con el thin sólo lo de host:port:sid Hay una direción especial para contactar con la BD local: se trata de dejar en blanco la localización de la BD. Se supone, entonces, que se desea conectar con la BD local: jdbc:oracle:oci@ Mucho ojo! El driver (el classes12.jar) a usar debe ser el correspondiente (exacto) a la versión instalada. Recomiendo copiar el classes12.jar de la carpeta en la que esté como resultado de la instalación y usar ese. Si no puede haber problemas de jaa.lang.UnsatisfiedLinkError en la llamada (ver Java Programming with Oracle JDBC cap 2).
- Recordar aquí lo de la Breve Intro a la ejec de Statements SQL en la BD que habré tendio que dar antes: alli se introducía el conepto de cursor, … Xej se puede ejecutar stmt.executeUpdate(&quot;begin Insert into mktg values(1000,'xxx'); Insert into mktg values(1001,'yyy'); end;&quot;); Inserta las dos tuplas
- Y según parece comprobarse aunque se cierre el resultset (cursor), si no se cierra el staement no se cierra definiivamente el cursor. Esto me paso en la aplicación de corregir lo de practicas de sql, que creaba muchos statements (no lo cerraba) en una misma conexión y aunque tuve l cuidado de cerar los resultsets me dio error de demaisados cusores abiertos. Cuando cere el satement no me dio mas el problema
- Hablar recordar un poco que es la optimización de consultas (referirles a la página web de la asignatura de BD en la que deben estar esos contenidos) y que es el plan de consulta. La sentencia se prepara y luego se ejecuta tantas veces como sea necesario con el plan de ejecución determinado durante la preparación
- Cada ? Será sustituido por un valor de campo. No vale para nombres de campos ni de tablas. Además al sustituir el valor se aplica el formato adecuado, ej si es varchar, se pone entre ‘’. Esto ayuda a comprender xq esto ESTA MAL String sql = “Select * from articulo where upper(nombre) like upper(‘%?%’)” al traducir hará … like upper(‘%’ algo’%’) MAL PreparedStatement ps = con.prepareStatement(sql); ps.setString(1,”algo”); Y SI ESTA BIEN String sql = “Select * from articulo where upper(nombre) like upper(?)” al traducir hará … like upper(‘%algo%’) BIEN PreparedStatement ps = con.prepareStatement(sql); ps.setString(1,”%algo%”); // Es aquí donde ponemos los % Inyecciones de SQL: Ejemplo teclear en el text de un form que pide el nombre de usr lo siguiente admin’ -- y dejar en balnco el de contrseña Si esto se inserta en el siguiente SQL select * from Users where idUsr=‘*’ and pwd=‘**’ Al componer el SQL queda select * from Users where idUsr=‘admin’ --’ and pwd=‘**’ Si el -- es el carácter de comentario esto hace que No se compruiebe la contraseña y se puede entrar en la aplicaicón. EL prepares evita esto xq trata el texto como texto El usar ’12-12-2004’ funciona en Access y en Oracle public class PruFehasAccess { public static void main(String[] args) { String url = &quot;jdbc:odbc:a&quot;; try { Class.forName(&quot;sun.jdbc.odbc.JdbcOdbcDriver&quot;); } catch (ClassNotFoundException e) { System.out.println(&quot;No se ha podido cargar el driver de la JDBC-ODBC&quot;); } Connection con = null; try { con = DriverManager.getConnection(url, &quot;&quot;, &quot;&quot;); Statement select = con.createStatement(); int i = select.executeUpdate(&quot;INSERT INTO a values('12-12-2003')&quot;); select.close(); con.close(); } catch (Exception e) { e.printStackTrace(); } finally { try { if (con != null) con.close(); } catch (SQLException ex) { } } } }
- Criticas al uso de ? Para defenderse del String Interpolation El uso de parámetros posicionales no escala bien: Para dar valor hay que usar la posición y si la query es larga es complicado de entender, tracear … Hay que dar muchos valores y se pierde el control No sirve para todas los casos: &quot;SELECT x, y, z FROM Table WHERE id IN ($set_of_ids)&quot;
- Cuando se trata de comparaciones no funciona bien y hay que poner el is null. Por ejemplo el código siguiente no funciona a no ser que pongamos lo del is null (no funciona no en Oracle ni en Access): package bd; import util.ResultSetDisplayer; import java.sql.*; public class PruebaPreparedConNull { // Registro del driver apropiado para la BD a utilizar static { try { Class.forName(&quot;sun.jdbc.odbc.JdbcOdbcDriver&quot;); } catch (ClassNotFoundException e) { System.out.println(&quot;No puedo cargar el driver JDBC de la BD&quot;); } } public static void main(String[] args) { try { Connection con = DriverManager.getConnection(&quot;jdbc:odbc:xx&quot;,&quot;&quot;,&quot;&quot;); PreparedStatement ps = con.prepareStatement(&quot;select * from finca where calefacción = ?&quot;); // PreparedStatement ps = con.prepareStatement(&quot;select * from finca where calefacción is null&quot;); Esto si funciona // ps.setString(1, null); ps.setNull(1, Types.VARCHAR); // Es lo mismo que lo de arriba y tp funciona bien ResultSet rs = ps.executeQuery(); ResultSetDisplayer rsd = new ResultSetDisplayer(rs); rsd.print(); rs.close(); ps.close(); con.close(); } catch (SQLException ex) { ex.printStackTrace(); } } }
- Oracle tiene dos (tres) tipos para fechas, lo de tres es por el Time que sólo almacena hora Aunque esta no existe en Oracle, la tercer es una TIMESTAMP with time zone
- No dejarse las {} y poner call en minúsculas Si no hay params no se pone (), aunque en Oracle da igual ponerlo que no, en JDBC. Es decir se puede poner {?=call TamanioMedioAlbum} o {?=call TamanioMedioAlbum()} Pero en SQL, no da igual call TamanioMedioAlbum() into :x; FUNCIONA call TamanioMedioAlbum into :x; NO FUNCIONA select TamanioMedioAlbum() from dual; FUNCIONA select TamanioMedioAlbum() from dual; FUNCIONA
- Ej: se puede contar algo sobre hacer un pedido: el usr mete varias líneas pero se equivoca y en una mete una cantidad negativa. EL sistema lo detecta en forma de restricción de integridad violada. El error debe ser reportado al usr, pues el sistema no sabe como corregirlo (no puede adivinar qué cantidad quería el usr). Pero lo que no puede ser es que quede el pedido a medias de meter (xq no corresponde con ningún pedido real, xq luego se va a intentar de nuevo y estría en parte duplicado, xq el usr se arrepiente y no quiere meterlo).
- Hay una pequeña diferencia en el comportamiento del nivel de aislamiento serializable en Java y el SQLPlus: Si se abren dos sesiones SQLPlus y se ponen a serializable, en ese momento es como si se hiciese una foto de cómo están las tablas. Si se hace un update+commit en una sesión en la otra el select devolverá el estado pre-update de la tabla alterada en la otra sesion. En java no es del todo así. Si se abren dos conexiones a una BD y se ponen a serializable; si se hace un update+commit en una sesión en la otra el cambio se ve o no dependiendo si hemos empezado ya a hacer cosas: si en la segunda sesión no se ha hecho ningún select se ve el cambio; si ya se ha hecho un select (aunque sea de otra tabla) el cambio no se ve.
- Cualquier error que puede aparecer en la ejecución normal: deadlock, no serializable, bloqueo no admitido, ... (mostrar la lista inmensa de errores posibles en ORA)
- Propiedades sobre lo que puede hacer la BD y el driver: procedimientos almacenados, outer joins, … transaciones select for update, savepoints, … Funciones que incluye la BD (to_date, …) y tipos que soporta
- {escape ‘’} en Oracle es … nombre like ‘\_%’ escape ‘’ y que las secuecnias {d ‘yyyy-mm-dd} no funcioa en SQL directamente Esto hace que la sintaxis de escape sea independiente de la DBMS y permite al programador usar características que de otro modo no estarían disponibles. Los caracteres “%” y “_” trabajan como comodines en la cláusula SQL LIKE (“%” significa cero o más caracteres y “_” significa exactamente un carácter”. En orden a interpretarlos literalmente, pueden estar precedidos por un backslash (‘’), que es un carácter de escape especial en cadenas. Se puede especificar un carácter que se use como carácter de escape por la inclusión de la sintaxis siguiente al final de la consulta. {escape 'escape-character'} Por ejemplo, la siguiente consulta, usando backslash como carácter de escape, encuentra nombres de identificador que comiencen con ‘_’. stmt.executeQuery(&quot;SELECT name FROM Identifiers WHERE Id LIKE '\_%' {escape ''};
- Las conexiones son un recurso limitado: hay que cerrarlas Pero cuando? ¿Tras cada transacción? ¿Se pueden conservar entre transacciones? Depende mucho del tipo de aplicación y de las necesidades se pueden conservar Si hay pocos usr concurrenetes Si hay que mantener las props de transacciones en varias interacciones Pero hay que comprobar que la conexión está viva (y no siempre funciona el isAlive() y hay que hacer queries como SELECT 7 FROM DUAL Hay que cerrarla si hay muchos usrs conectados concurrentemente, por ejemplo en portales (pensar que si la sesión duran 30 m en 30 m pueden entrar miles de usrs). En estos casos tras cada servicio hay que cerrar la conexión. Se suelen usar Pool de conexiones
- (ver tb http://www.theserverside.com/news/1365244/Why-Prepared-Statements-are-important-and-how-to-use-them-properly ) Ultima opnión de Kyte leída: The use of a Statement in JDBC should be 100% localized to being used for DDL (ALTER, CREATE, GRANT, etc) as these are the only statement types that cannot accept BIND VARIABLES. PreparedStatements or CallableStatements should be used for EVERY OTHER type of statement (DML, Queries). As these are the statement types that accept bind variables. This is a fact, a rule, a law -- use prepared statements EVERYWHERE. Use STATEMENTS almost no where. (ver C:usrFranMasterJDBCAsk-Tom- Statements vs PreparedStatements.doc) Segun Thomas Kyte, SIEMPRE ES MEJOR Prepared que Statement. Exise un bechmark que será el que leí yo en su dñia que decía que sólo era mejor si se repetía muchas veces la query. Pero kyte analiza xq salía ese resulatdo y corrige el test para comprobar que siempre es mejor (ver Effectie Oracle By Design; Oracle Press pág 273). Why Prepared Statements are important and how to use them &quot;properly&quot; Databases have a tough job. They accept SQL queries from many clients concurrently and execute the queries as efficiently as possible against the data. Processing statements can be an expensive operation but databases are now written in such a way so that this overhead is minimized. However, these optimizations need assistance from the application developers if we are to capitalize on them. This article shows you how the correct use of PreparedStatements can significantly help a database perform these optimizations. How does a database execute a statement? Obviously, don't expect alot of detail here; we'll only examine the aspects important to this article. When a database receives a statement, the database engine first parses the statement and looks for syntax errors. Once the statement is parsed, the database needs to figure out the most efficient way to execute the statement. This can be computationally quite expensive. The database checks what indexes, if any, can help, or whether it should do a full read of all rows in a table. Databases use statistics on the data to figure out what is the best way. Once the query plan is created then it can be executed by the database engine. It takes CPU power to do the access plan generation. Ideally, if we send the same statement to the database twice, then we'd like the database to reuse the access plan for the first statement. This uses less CPU than if it regenerated the plan a second time. Statement Caches Databases are tuned to do statement caches. They usually include some kind of statement cache. This cache uses the statement itself as a key and the access plan is stored in the cache with the corresponding statement. This allows the database engine to reuse the plans for statements that have been executed previously. For example, if we sent the database a statement such as &quot;select a,b from t where c = 2&quot;, then the computed access plan is cached. If we send the same statement later, the database can reuse the previous access plan, thus saving us CPU power. Note however, that the entire statement is the key. For example, if we later sent the statement &quot;select a,b from t where c = 3&quot;, it would not find an access plan. This is because the &quot;c=3&quot; is different from the cached plan &quot;c=2&quot;. So, for example: for ( int I = 0; I < 1000; ++I) { PreparedStatement ps = conn.prepareStatement(&quot;select a,b from t where c = &quot; + I); ResultSet rs = Ps.executeQuery(); Rs.close(); Ps.close(); } Here the cache won't be used. Each iteration of the loop sends a different SQL statement to the database. A new access plan is computed for each iteration and we're basically throwing CPU cycles away using this approach. However, look at the next snippet: PreparedStatement ps = conn.prepareStatement(&quot;select a,b from t where c = ?&quot;); for(int I = 0; I < 1000; ++I) { ps.setInt(1, I); ResultSet rs = ps.executeQuery(); Rs.close(); } ps.close(); Here it will be much more efficient. The statement sent to the database is parameterized using the '?' marker in the sql. This means every iteration is sending the same statement to the database with different parameters for the &quot;c=?&quot; part. This allows the database to reuse the access plans for the statement and makes the program execute more efficiently inside the database. This basically let's your application run faster or makes more CPU available to users of the database. PreparedStatements and J2EE servers Things can get more complicated when we use a J2EE server. Normally, a prepared statement is associated with a single database connection. When the connection is closed, the preparedstatement is discarded. Normally, a fat client application would get a database connection and then hold it for its lifetime. It would also create all prepared statements eagerly or lazily. Eagerly means that they are all created at once when the application starts. Lazily means that they are created as they are used. An eager approach gives a delay when the application starts but once it starts then it performs optimally. A lazy approach gives a fast start but as the application runs, the prepared statements are created when they are first used by the application. This gives an uneven performance until all statements are prepared but the application eventually settles and runs as fast as the eager application. Which is best depends on whether you need a fast start or even performance. The problem with a J2EE application is that it can't work like this. It only keeps a connection for the duration of the request. This means that it must create the prepared statements every time the request is executed. This is not as efficient as the fat client approach where the prepared statements are created once, rather than on every request. J2EE vendors have noticed this and designed connection pooling to avoid this performance disadvantage. When the J2EE server gives your application a connection, it isn't giving you the actual connection; you're getting a wrapper. You can verify this by looking at the name of the class for the connection you are given. It won't be a database JDBC connection, it'll be a class created by your application server. Normally, if you called close on a connection then the jdbc driver closes the connection. We want the connection to be returned to the pool when close is called by a J2EE application. We do this by making a proxy jdbc connection class that looks like a real connection. It has a reference to the actual connection. When we invoke any method on the connection then the proxy forwards the call to the real connection. But, when we call methods such as close instead of calling close on the real connection, it simply returns the connection to the connection pool and then marks the proxy connection as invalid so that if it is used again by the application we'll get an exception. Wrapping is very useful as it also helps J2EE application server implementers to add support for prepared statements in a sensible way. When an application calls Connection.prepareStatement, it is returned a PreparedStatement object by the driver. The application then keeps the handle while it has the connection and closes it before it closes the connection when the request finishes. However, after the connection is returned to the pool and later reused by the same, or another application, , then ideally, we want the same PreparedStatement to be returned to the application. J2EE PreparedStatement Cache J2EE PreparedStatement Cache is implemented using a cache inside the J2EE server connection pool manager. The J2EE server keeps a list of prepared statements for each database connection in the pool. When an application calls prepareStatement on a connection, the application server checks if that statement was previously prepared. If it was, the PreparedStatement object will be in the cache and this will be returned to the application. If not, the call is passed to the jdbc driver and the query/preparedstatement object is added in that connections cache. We need a cache per connection because that's the way jdbc drivers work. Any preparedstatements returned are specific to that connection. If we want to take advantage of this cache, the same rules apply as before. We need to use parameterized queries so that they will match ones already prepared in the cache. Most application servers will allow you to tune the size of this prepared statement cache. Comentarios del documento de consultoria de reingeniería de Saunier Duval (pueden estar obsoletos – HAY ERRORES según Thomas Kyte (ver coemntario de arriba)) Sobre el uso de PreparedStatement en vez de Statements El API Java para acceso a bases de datos (JDBC) proporciona dos instrumentos para la realización de consultas y actualizaciones: Statement y PreparedStatement. El propósito del segundo es optimizar la ejecución de la operación. Para ello el driver accede una vez a la BD para recuperar los metadatos asociados a la consulta (tipos, estructuras de tablas, …) y los reutiliza en posteriores accesos. En contraposición, un Statement hace dos accesos a la BD cada vez: uno para recuperar los metadatos asociados a la operación, y otro para ejecutarla. Podría pensarse, por tanto, que usar un PreparedStatement siempre será más eficiente que emplear su correspondiente Statement. Sin embargo los datos experimentales no demuestran tal cosa: En primer lugar es preciso aclarar que casi todos los gestores de base de datos realizan un cacheo interno de las consultas (selects) que procesan, almacenando el plan de ejecución para posteriores reutilizaciones. El efecto de PreparedStatement en consultas se ve superado por esta optimización a nivel de SGBD, por lo que su empleo se ha de limitar a el caso de consultas de actualización (insert, update, delete). Un objeto PreparedStatement está vinculado a la conexión JDBC que lo crea, por lo que, si se cambia de conexión, se debe crear y recompilar de nuevo, eliminándose, evidentemente, el efecto de la optimización. A pesar de que pudiera parecer que a partir de la segunda ejecución, y posteriores, un PreparedStatement es al menos un 50 % más rápido que un Statement, experimentalmente es posible comprobar que el rendimiento de PreparedStatement no es superior al de Statement hasta que al consulta no se repite unas 125 veces( Utilizando el Thin driver de Oracle, sobre base de datos Oracle 8.1.6) . La sobrecarga de utilización de un objeto PreparedStatement (el tiempo de preparación de la operación es siginificativamente más grande que el de la correspondiente Statement) explica este comportamiento. Ya que cada PreparedStatement está asociado con cada conexión, que en el portal se utiliza un pool de conexiones (de tamaño mínimo 10), que, para sacar partido de la optimización, es preciso repetir la ejecución de cada PreparedStatement más de 100 veces, que las conexiones en el pool son destruidas periódicamente para evitar problemas de obsolescencia, y que las consultas que se pueden optimizar (actualizaciones) son menos habituales, se deduce que es muy difícil garantizar una mejora en el rendimiento imputable al uso de PreparedStatement. Si a lo anterior añadimos la consideración del sobre-coste de diseño y codificación que implica el empleo de este tipo de objetos JDBC
- SOLO vale para Statement. Si se prueba a hacer con PreparedStatement fall (método no soportado). Al menos en Oracle. SI no se dice nada no es transacional. Es decir cada instrucción del lote se autoconfirma. Se puede comprobar con el siguiente codigo (en el que se hace fallar al lote al incluir un dato que viola una restricción). Se comprueba que los datos anteriores si están en la BD (si se hace un setAutocomit false ya no estárán los datos): import bd.ConnectionManager; import java.sql.Connection; import java.sql.*; public class PruBatch { public static void main(String[] args) { initBD(); añadeDatos(); } private static void initBD() { Connection con = null; try { con = ConnectionManager.getConnection(); Statement stm = con.createStatement(); stm.addBatch(&quot;drop table AAAA cascade constraints&quot;); stm.addBatch(&quot;create table AAAA (a Number(1,0) check (a>0))&quot;); stm.executeBatch(); stm.close(); } catch (SQLException ex) { ex.printStackTrace(); } finally { if (con != null) { try { ConnectionManager.returnConnection(con); } catch (SQLException ex1) { ex1.printStackTrace(); } } } } private static void añadeDatos() { Connection con = null; try { con = ConnectionManager.getConnection(); Statement stm = con.createStatement(); stm.addBatch(&quot;insert into AAAA values (1)&quot;); stm.addBatch(&quot;insert into AAAA values (2)&quot;); stm.addBatch(&quot;insert into AAAA values (3)&quot;); stm.addBatch(&quot;insert into AAAA values (-4)&quot;); stm.addBatch(&quot;insert into AAAA values (5)&quot;); stm.executeBatch(); stm.close(); } catch (SQLException ex) { ex.printStackTrace(); } finally { if (con != null) { try { ConnectionManager.returnConnection(con); } catch (SQLException ex1) { ex1.printStackTrace(); } } } } }
- ResultSet.TYPE_SCROLL_INSENSITIVE , una vez consultados los datos si estos son cambiados por terceros no veremos los cambios. Los cambios no se sincronizan De esto habla un poco el libro “Databases and Transaction Processing”, pág 305. Scroll insensitive : Usa un cursor INSENSITIVE supone que una vez hecha la consulta los cambios realizados en las tablas subyacentes a la consulta por otros usuarios, transacciones, sesiones (como quiera verse) o por la misma transacción que creo el resultset (que puede, tras consultar el resultset, hacer cambios en la stablas y seguir teniendo el result set a medias de procesar), que esos cambios no son visibles por el result set Scroll sensitive: usa un Cursor SENSITIVE. SQL standard no define un comportamiento esperado cunado la opción INSENSITIVE. Los abricantes de SGBD pueden hacer lo que quieran y JDBC lo que hace es proporcionar la semántica del SGBD subyacente. Muchos usan lo que se denomina semantica KEYSET_DRIVEN, por la cual los updates y deleets son visibles pero los inserts no. Para actualizar hay una serir de métodos update<Tipo> y luego se hace updateRow(). Tambien se puede hacer insertRow() para añadir una fila vacía y luego grabarla con updateRow. El control de la concurrencia los cambios he leido que se hace con locks de escritura, de modo que solo un cada vez puede tener el resultset; otras implementacione spueden usar estrategias optimistas. Ej: con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_UPDATABLE ); Luego, para cambiar los datos se usan métodos updateXxx(). Por ejemplo: ResultSet rs = stmt.executeQuery(&quot;SELECT * FROM Cosa&quot;); while (rs.next()) { if ( true ) { double delta = 8; double precio = rs.getDouble(&quot;Precio&quot;); rs. updateDouble (&quot;Precio&quot;, precio+delta); rs. updateRow (); }
- Incluso en drivers que si las soportan, determinadas queries complejas pueden devolver resultados que por ejemplo no sean modificables : supongo (eso es mio) que pasará algo parecido a lo que sucede con las vistas; habrá resultados que no se puedan actualizar: uniones, groups, ...
- JDBC 3 incluye cosas sobre (ver tb http://www.ibm.com/developerworks/java/library/j-jdbcnew/): - conexiones: parametros standard - cacheo/pooling de prepared statements - parámetros con nombre (no solo posición) en CallableStatements - resultset que no se cierran al hacer commit en la conexión (resultSet holdability) - se pueden tener abiertos a la vez en instrucciones que devuelvan varios resultsets - Se pueden recuperar los valores autogenerados que se suelen usar en campos clave (en SGBD que lo permitan, claro; Oracle lo dudo) - mejoras en resultset para poder get y set tipos CLOB BLOB y ARRAY
- The DriverManager.getConnection method has been enhanced to support the Java Standard Edition Service Provider mechanism. JDBC 4.0 Drivers must include the file META-INF/services/java.sql.Driver. This file contains the name of the JDBC driver’s implementation of java.sql.Driver.
- Interrogación didáctica – evaluación formativa Cuál es el proceso de trabajo con JDBC? (cargar driver, abrir conexión, statem, procesar, cerrar) ¿Cómo se procesa un ResultSet? (next y getXXX) ¿Hay que cerrar el ResultSet? ¿Hay que cerrar la conexión? Hemos dicho “La aplicación no suele trabajar directamente con el Driver concreto”. ¿Qué pasaría si trabajasemos con un driver concreto en una determinada aplicación (falta de genericidad)? ¿Qué hay que hacer para que una aplicación construida con JDBC cambie la BD sobre la qe trabaja (cambiar los params de conexión) Cosas a mandar: Lectura/escritura de CLOBS CachedRowSet