Update vs cursor

el while puede ser sobre un exists o un select no sobre cada fila, a eso me
referia.
"Carlos Sacristan" wrote in message
news:
Mostrar la cita

Depende del cursor y de cómo esté implementado el bucle WHILE.

De todos modos, a lo que me refería es que ambas soluciones (WHILE o
CURSOR) hacen procesamiento fila a fila, algo que normalmente perjudica el
rendimiento respecto de una solución orientada a conjuntos.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"aa" wrote in message
news:
Mostrar la cita

El cursor trabaja sobre temporales y consume mas recursos,con while se
pueden hacer cosas con los select para limitar que son mas performantes.
"Carlos Sacristan" wrote in message
news:
Mostrar la cita

En realidad sí las tiene. Aunque los resultados de TOP(n) y ROWCOUNT son
similares, hay ciertas cosas que hay que tener en cuenta en su uso. En
el apartado "TOP frente a SET ROWCOUNT" del tema "Limitar los conjuntos
de resultados con TOP y PERCENT"
http://msdn.microsoft.com/es-es/lib...87043.aspx de los BOL viene
bien explicado.

Tampoco veo muy bien las ventajas de usar WHILE en vez de un cursor...
al final el procesamiento fila a fila es el mismo en un caso que en el
otro.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"aa" wrote in message
news:
Mostrar la cita

Set rowcount lo unico que hace es una especie de "top",no tiene
contraindicaciones.
Igualmente siempre hay mejores maneras hasta con while de controlar
flujo de datos sin pasar por cursores.
"Aguardientico" <gusgon1 at nospam dot com> wrote in message
news:
Mostrar la cita

Hola aa,

Lastimosamente el uso de set rowcount no es recomendado y además yo
necesitaba procesar todos los registros y el rowcount para al llegar
al numero indicado.

En mi escenario no tenia ningun campo que me permitiera controlar el
numero de registro (no existían pk's ni columnas unique) por lo que la
unica solucion era a través de cursores.

A lo que quiero llegar es que para cada escenario pueden haber
diferentes soluciones y solo haciendo un aálisis correcto se puede
determinar cual es la mejor solución.

Lo que nosostros pensamos que en un caso tiene muy buen performance
para otro caso puede llegar a ser pésimo.

Atte.

Gustavo Gonzalez

"aa" wrote in message
news:
Mostrar la cita

En ese caso tenes que tener un set rowcount 250000
y cada sentencia ejecuta solo sobre 250000 registros.
"Aguardientico" <gusgon1 at nospam dot com> wrote in message
news:%
Mostrar la cita

Hola Cesar,

Te cuento que el hacer un update en base a un select es mucho mejor
que usar un cursor pero.

Te comento que una vez tuve que hacer una migración de datos, eran
aprox. 10 millones de registros por tabla.

Traté de hacer algunas actualizaciones basadas en select's pero
lastimosamente generaba mucho log para poder controlar rollbacks,
así que la forma más eficiente que encontré para poder hacerlo fue
basado en cursores para poder hacer commit's cada cierta cantidad de
registros.

Gustavo Gonzalez

"AAAAA" wrote in message
news:
Mostrar la cita

Hola amigos,
Estoy haciendo un update de una tabla a otra de forma masiva con un
select en el update, me han comentado que mejor use un cursor qu e
es mas rapido, es eso verdad donde puedo encontrar sustento sobre
eso?

Saludos

Cesar


__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4631 (20091123) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Hola aa.

Disculpame por responder despues de tanto tiempo pero adjunto un par de url
para demostrar que no en todos los casos es malo usar un cursor.

http://blogs.techrepublic.com.com/datacenter/?p41
http://blogs.techrepublic.com.com/d...rbxccnbtr1

Esto no es con el proposito de discutir sino para las personas sin un
conocimiento avanzado puedan tomar mejores decisiones de diseño con respecto
a las aplicaciones con bases de datos.

Atte.

Gustavo Gonzalez


"aa" wrote:

Mostrar la cita

Set rowcount lo unico que hace es una especie de "top",no tiene
contraindicaciones.
Igualmente siempre hay mejores maneras hasta con while de controlar flujo de
datos sin pasar por cursores.
"Aguardientico" <gusgon1 at nospam dot com> wrote in message
news:
> Hola aa,
>
> Lastimosamente el uso de set rowcount no es recomendado y además yo
> necesitaba procesar todos los registros y el rowcount para al llegar al
> numero indicado.
>
> En mi escenario no tenia ningun campo que me permitiera controlar el
> numero de registro (no existían pk's ni columnas unique) por lo que la
> unica solucion era a través de cursores.
>
> A lo que quiero llegar es que para cada escenario pueden haber diferentes
> soluciones y solo haciendo un aálisis correcto se puede determinar cual es
> la mejor solución.
>
> Lo que nosostros pensamos que en un caso tiene muy buen performance para
> otro caso puede llegar a ser pésimo.
>
> Atte.
>
> Gustavo Gonzalez
>
> "aa" wrote in message
> news:
>> En ese caso tenes que tener un set rowcount 250000
>> y cada sentencia ejecuta solo sobre 250000 registros.
>> "Aguardientico" <gusgon1 at nospam dot com> wrote in message
>> news:%
>>> Hola Cesar,
>>>
>>> Te cuento que el hacer un update en base a un select es mucho mejor que
>>> usar un cursor pero.
>>>
>>> Te comento que una vez tuve que hacer una migración de datos, eran
>>> aprox. 10 millones de registros por tabla.
>>>
>>> Traté de hacer algunas actualizaciones basadas en select's pero
>>> lastimosamente generaba mucho log para poder controlar rollbacks, así
>>> que la forma más eficiente que encontré para poder hacerlo fue basado en
>>> cursores para poder hacer commit's cada cierta cantidad de registros.
>>>
>>> Gustavo Gonzalez
>>>
>>> "AAAAA" wrote in message
>>> news:
>>>> Hola amigos,
>>>> Estoy haciendo un update de una tabla a otra de forma masiva con un
>>>> select en el update, me han comentado que mejor use un cursor qu e es
>>>> mas rapido, es eso verdad donde puedo encontrar sustento sobre eso?
>>>>
>>>> Saludos
>>>>
>>>> Cesar
>>>>
>>>>
>>>> __________ Information from ESET NOD32 Antivirus, version of virus
>>>> signature database 4631 (20091123) __________
>>>>
>>>> The message was checked by ESET NOD32 Antivirus.
>>>>
>>>> http://www.eset.com
>>>>
>>>>
>>>>
>>>
>>> __________ Information from ESET NOD32 Antivirus, version of virus
>>> signature database 4634 (20091124) __________
>>>
>>> The message was checked by ESET NOD32 Antivirus.
>>>
>>> http://www.eset.com
>>>
>>>
>>>
>>
>>
>>
>> __________ Information from ESET NOD32 Antivirus, version of virus
>> signature database 4634 (20091124) __________
>>
>> The message was checked by ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>>
>>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4634 (20091124) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>


.