Optimización de tiempo de ejecución de Update en Sentencia SQL
Hola a tod@s.
Como sigo siendo algo lelo en temas de SQL os consulto a ver si me podéis echar un cable. Supongamos que tengo dos tablas con los siguientes campos: Código:
MOVIMIENTOS Código:
CLIENTES
Esto funciona pero si atacamos a una tabla MOVIMIENTOS de unos cuantos miles de registros se hace lento. Necesitaría ver si hay una forma de hacer que solo se actualicen en la tabla MOVIMIENTOS los registros correspondientes a los clientes que tengan un TIPO determinado para acotar el número de registros a actualizar en función de los clientes que tengan ese TIPO determinado, o sea, que solo actualice los registros de la tabla MOVIMIENTOS que afecten a clientes que tengan en la tabla CLIENTES el tipo 1 por ejemplo. No sé si "mexplico". Gracias y un saludo |
Añádele la condición que quieres:
De todas formas es raro que sea lento. |
Hola.
Pensé en la misma opción que te dá Casimiro, pero le agregaría: para evitar que asigne NULL cuando la consulta arroje resultados no coincidentes. Lo que no sé, es si será mas eficiente que la primera... Saludos :) |
En mi opinión, la asignación via subconsulta es muy lenta. Yo haría algo así:
// Saludos |
Por cierto, ¿nadie va a regañar al forista por tan mala selección de título para su mensaje? :D
// Saludos |
Cita:
:rolleyes: |
A Newtron me lo respetan...:cool:
:p |
Cita:
Cita:
Cita:
Gracias a todos, haré pruebas y os comento qué me resulta más eficiente. |
Bueno.
He hecho pruebas y las soluciones de Casimiro y ecfisa tardan lo mismo que la mía inicial con la diferencia de que, como bien dice ecfisa, con la de Casimiro asigna valor null cuando los resultados no son coincidentes así que nos quedamos como estamos. La consulta de roman no me funciona, me dice exactamente "Expected SET but instead found LEFT", o sea, que después del "UPDATE....." no deja poner otra cosa que no sea "SET ...". Igual eso funciona en Firebird pero en mi base de datos (ElevateDB) no va. Efectivamente el problema de la lentitud es que por cada linea de la tabla MOVIMIENTOS tiene que hacer un SELECT a la tabla CLIENTES para buscar el valor cuando sería bastante más rápido que fuera a buscar primero a la tabla CLIENTES los registros que coincidan con el campo TIPO=loquesea y luego fuera a la tabla MOVIMIENTOS y cambiara solo los de esos clientes, que en este caso serían pocos. Saludos |
Yo probaría a hacer dos consultas. Primero, encontrar la lista de registros que tienen que actualizarse (y los valores a asignar), y luego hacer la actualización en un bucle. Puede que sea más rápido, o no, que no lo he probado.
|
Cita:
Gracias por el comentario. |
Decir mi programa es "Lento", es como cuando dicen "mi programa tiene un problema".
Programador profesional? No se aceptan esas afirmaciones. Por fa: - Define lento - Define rapido - Define tamaño ("cuantos miles"?????) - Usa profiling (DONDE es lento), y en este caso, muestra el plan de ejecucion - Ambiente de ejecución (Que motor, version, RAM, CPU, uso de CPU, RAM, DISCO) = Que exactamente? Pues pa eso es el profiling. |
Cita:
Lento: lo suficiente para preguntar en el foro Rápido: lo suficiente para no preguntar en el foro Tamaño: el de mi tabla real Profiling: es lento desde que empieza hasta que termina :p :D // Saludos |
Cita:
Yo solamente he puesto una sentencia SQL y preguntaba si había forma de optimizarla (como bien me han corregido en el título del post) no creo que para eso haya que dar un informe "hipermegadetallado" de la situación. Gracias por tu interés y un saludo |
Cita:
Cita:
Para ser mas conciso? Casi siempre se puede reducir a plan de ejecución. Y chico, que motor es??? Dependiendo de cual se puede usar esto o aquello, pero asi en la oscuridad total.... ---- P.D: Y porque eso no esta en un trigger? |
Cita:
Cita:
Cita:
Resumiendo, que es lo que hay y ya está, si el usuario tiene que esperar un poco a que se ejecute la instrucción que espere. Gracias a todos por vuestros comentarios y un saludo. |
Ya se que de esto hace una semana pero tenia ganas de poner algo en el foro. :D
Mi SQL para SQL Server seria
Espero que ayude. |
Ok, gracias pero hay algo que no veo claro:
con esto lo que haces es actualizar solo los que en la tabla de movimientos tienen el campo TIPO=NULL, ¿no?. La idea es evaluar en la tabla MOVIMIENTOS solo los movimientos correspondientes a los clientes que tengan X en el campo TIPO sin tener que hacer una búsqueda en la tabla CLIENTES por cada registro de la tabla MOVIMIENTOS. Saludos |
Buenas newtron,
La clausula where es para updatar solo los que no tienen valor en el campo TIPO, de esta forma optimizamos la consulta y no volvemos a modificar registros que ya tienen un valor correcto. Pero si CLIENTES se modifica en la tabla MOVIMIENTOS después puedes quitar la clausula para modificar todos los registros, aunque no es muy optimo. Saludos. |
Cita:
Gracias y un saludo |
La franja horaria es GMT +2. Ahora son las 23:01:49. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi