Foro sobre Java SE > ¿Funciones de BD más lentas que SQL embebidos en JAVA?
Guenas.
No se que tal ira con PostgreSQL, pero tengo comprobado que con Oracle es mas rapido usar SQL directo desde JDBC que llamar a funciones de packages PLSQL.
Un saludo
![Unregistered Commenter Unregistered Commenter](/universal/images/transparent.png)
Como dice @Paposo, no se puede afirmar que las funciones almacenadas son, por definición, más rápidas que los comandos embebidos. A veces sí, a veces no.
No creo que sea acertado afirmar "que la mejor forma de programar" sea usar funciones almacenadas, por ese motivo.
Tampoco "por razones de seguridad": si se usan Prepared Statements no hay riesgo de SQL Injection; lo mismo que si se usa "private static final" en las declaraciones explícitas de comandos SQL.
Si buscas un buen rendimiento, sobre todo en los query, prueba a usar esta base de datos:
http://www.h2database.com/html/performance.html
![Registered Commenter Registered Commenter](/universal/images/transparent.png)
Gracias por sus comentarios y recomendaciones...
Ya encontré el problema por el cual se daba esta situacion
Pues resulta que en una de esas que hice un insert de alrededor de 100.000 registros, al hacer la consulta con el
SELECT puro insertado en el codigo JAVA se puso muy lento... entonces fue cuando pense que quizas se necesitaba
hacer un vacuum y reindexar las tablas de las bases de datos...
cuando lo hice el tiempo de respuesta de la consulta volvio a la normalidad,
Me puse a pensar un poco al respecto y fue cuando me di cuenta que siempre por defecto en el modulo de configuración del
gestor de la base de datos Postgres hay un parámetro se llama "autovacuum" lo revise y estaba en ON y pense que cada vez que se hacía una transacción
en la base de datos este hacía automaticamente el VACUUM por lo que se relentizaba en las consultas y demas procesos.
Lo puse en OFF y ¡VOLIE! el tiempo de respuesta al llamar a los stored procedure redujo ostenciblemente aunque no al mismo nivel que
hacer el SQL dentro del codigo de JAVA...
muestro los datos que me arrojo como resultado
consulta a una tabla de 600.000 registros para mostrar 100.000 en pantalla con el parámetro AUTOVACUUM en OFF
- con stored procedure 5.30 segundos
- con SQL insertado en codigo JAVA 3.70
antes con una tabla de solo 30.000 registros para mostrar 12.000 en pantalla con con el AUTOVACUUN en ON
- con stored procedure 15 segundos o mas
- con SQL insertado 2 segundos o 3.
este parametro viene por defecto en ON por lo que uno tiene que desactivar manualmente cuando se instala el servidor de base de datos.
como podrán ver aun asi el SQL embebido en JAVA sigue siendo lijeramente más rápido que el stored procedure pero al menos
con el tipo de consultas y transacciones que necesito hacer me parece que el tiempo de respuesta es razonable como para implementarlo
en mi aplicación JAVA...
cualquier comentario sobre todo de los resultados obtenidos con la consulta en la tabla con mas de 100.000 registros les agredecería mucho
![Unregistered Commenter Unregistered Commenter](/universal/images/transparent.png)
Guenas.
Como dice choces cada BD es un mundo aparte. Tambien el driver JDBC empleado tiene una gran afectación sobre la "perfomance" de la BD. Por ultimo te diré que la estructura de la BD empleada tiene el 90% de responsabilidad en el rendimiento, sean procedimientos locales almacenados o llamadas JDBC explicitas.
Como comentario al margen te diré que se llevan de hostias optimizar la BD para un rabioso online que para consultas masivas. O uno u otro. Todo lo que optimice una consulta penaliza inserciones o updates y a la inversa. Si necesitas ambas cosas quizá deberías plantearte usar una BD para su uso online (Inserciones, actualizaciones) y otra replicada de alguna forma para explotación de la información.
En cualquiera de los casos, tal como insinuaba choces, te aconsejo que uses PreparedStatement usando variables antes que montar la query sobre la marcha. La diferencia es mas que notable en cualquier BD. Las llamadas a procedimientos almacenados quizá mejoren el rendimiento o quizá no. Lo mejor es probarlo y decidir en consecuencia. Con Oracle lo he probado en muchísimos casos y sin la menor duda me decanto por java antes que por plsql. Lo que no he probado es usar java para crear los procedimientos almacenados. Probablemente sea lo mas eficiente ya que java es sin duda mas rapido que plsql y si se ejecuta dentro del propio motor, aunque solo sea por el ahorro en movimientos, debería ser mas rápido.
Otra cosa que te recomiendo es no usar el driver ODBC-JDBC. Eso es para casos extremos que no exista el JDBC directo y por tanto no exista otra solución, pero es rarísimo que ocurra en cualquier motor mínimamente decente.
Y no te ofusques!!!!! El uso de la BD es mas un arte que una técnica :).
Optimiza primero las partes mas "sagradas" (normalmente el online) y cuando funcionen a tu medida dedícate a optimizar el resto ignorando métodos que penalicen anteriores optimizaciones.
Salut
![Unregistered Commenter Unregistered Commenter](/universal/images/transparent.png)
Saludos amigos del foro...
¿Que tal son para Java y base de datos PostgreSQL, bueno yo recien estoy comenzando...
Se supone que el trabajar con funciones almacenadas en la base de datos y views es mas rápido el proceso de búsqueda que
el utilizar las instrucciones SQL dentro del codigo de programación en este caso JAVA... pero, que curioso, al hacer una
consulta en una tabla de PostgreSQL de 30.000 registros usando una función interna de la BD se demora alrededor de unos 15 a 20 segundos,
pero si lo hago usando SQL embebido en el codigo JAVA solo se demora unos 2 a 3 segundos.
No se si tiene que ver con la manera en se se llama a la funcion; he usado dos modos el select * from "esquema"."nombre de funcion"(parámetros)
y tambien uso la clase CallabledStatement. pero con ambos se demoran lo mismo de 15 a 20 segundos o mas incluso, pero cuando dentro del
codigo uso el select campo1, campo2,... from tabla1, tabla2,... where condición1, condición2, order by etc solo demora 2 o tres segundos
no he usado los inner join, outter join etc que se supone la consulta se la hace mas rápida aun,
Alguien tiene idea acerca de esta particularidad que me ayude, he buscado información en la web pero no he encontrado nada al respecto
y me preocupa mucho ya que estoy desarrollando una aplicacion en la que se trabaja con tablas de hasta casi 1 millón de registros...
porque digo que me preocupa, ya que aparentemente puedo hacer que el proceso de busqueda se mas rapida de una forma que otra, pues debido
a que se supone que la mejor forma de programar es usando funciones de BD y es poco recomendable usar SQL embebidas, ademas tambien por
asuntos de seguridad en el acceso a datos...
les agradezco su ayuda