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:

Necesito rellenar el campo TIPO de la tabla MOVIMIENTOS con el campo TIPO de la tabla CLIENTES, una forma sería:

Código SQL [-]
UPDATE MOVIMIENTOS
SET TIPO=SELECT TIPO FROM CLIENTES WHERE MOVIMIENTOS.CLIENTE=CLIENTES.CODIGO

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:

Código SQL [-]
UPDATE MOVIMIENTOS
SET TIPO = (SELECT TIPO FROM CLIENTES WHERE MOVIMIENTOS.CLIENTE=CLIENTES.CODIGO and clientes.tipo=1)

De todas formas es raro que sea lento.

Hola.

Pensé en la misma opción que te dá Casimiro, pero le agregaría:

Código SQL [-]
UPDATE MOVIMIENTOS MV
SET TIPO = COALESCE((SELECT TIPO FROM CLIENTES CL WHERE MV.CLIENTE = CL.CODIGO AND CL.TIPO = :PTIPO),
                     MV.TIPO);

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í:

Código SQL [-]
update movimientos
left join clientes on clientes.codigo = movimientos.cliente
set movimientos.tipo = coalesce(clientes.tipo, movimientos.tipo)

// Saludos

Por cierto, ¿nadie va a regañar al forista por tan mala selección de título para su mensaje? :D

// Saludos

Estos novatos...
:rolleyes:

A Newtron me lo respetan...:cool:

:p

:eek::mad: "susvaisanterar"


^\||/:D

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.

Ciertamente es otra forma, lo que no sé es que si la lista de valores a actualizar, y por lo tanto de vueltas en el bucle, es mucha igual no es rentable.

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.

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

El amigo roman ha explicado con total exactitud lo mismo que yo te diría. Lento o rápido son conceptos subjetivos pero para darte un dato exacto y objetivo necesitaría darte montañas de información que no vienen al caso como procesador, capacidad, tipo y características del disco duro, memoria RAM, tipo de memoria RAM, modo local o en red, base de datos, campos de la base de datos, número de registros, número de tablas de la base de datos..... un sin fin de información que no viene al caso.

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

Por eso hay que aterrizarlos... Ademas que Casimiro dio la solucion obvia al problema. Y da la impresion de que no mejoro nada?

Por eso puse " Que exactamente? Pues pa eso es el profiling." No es necesario dar mucha información, pero si la relevante.

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?

Negativo, como ya comenté tarda exactamente lo mismo porque sigue haciendo un SELECT a la tabla CLIENTES por cada registro de la tabla MOVIMIENTOS.

Bueno, también comentaba que el motor de base de datos es ElevateDB pero hasta eso es irrelevante en cierta medida porque siendo compatible SQL 2003 da igual el motor que sea (creo).

Esa si que es una buena observación. No está en un trigger porque es un campo que se utiliza en una opción del programa que pueden usar un 1% de los usuarios y creo que no merece la pena montar triggers y un índice en la tabla para mantener ese campo actualizado.

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

Código SQL [-]
update movimientos
set tipo = c.TIPO
from movimientos m
join clientes c on c.codigo = m.cliente
where m.TIPO is null

Espero que ayude.

Ok, gracias pero hay algo que no veo claro:

Código Delphi [-]
where m.TIPO is null

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.

Claro, ese es el problema, que en la tabla MOVIMIENTOS el campo TIPO no se mantiene de forma automática y por eso mi pregunta venía a ser si había alguna instrucción que solo fuera a buscar los registros de la tabla MOVIMIENTOS en los que intervinieran los CLIENTES que cumplieran un tipo determinado pero veo que eso no se puede hacer.

Gracias y un saludo