Optimización de tiempo de ejecución de Update en Sentencia SQL

[mamcx]

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.

[roman]

Empezado por mamcx

- 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



// Saludos

[[newtron]]

Empezado por mamcx

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.

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

[mamcx]

Lento o rápido son conceptos subjetivos

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

necesitaría darte montañas de información

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?

[[newtron]]

Empezado por mamcx

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

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

Empezado por mamcx

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....

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).

Empezado por mamcx

P.D: Y porque eso no esta en un trigger?

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.

[Salvi]

Ya se que de esto hace una semana pero tenia ganas de poner algo en el foro.

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.

[[newtron]]

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

[Salvi]

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.