Problemas con subtotales

[[fjcg02]]

Hola a todos,
el tipo de consultas que propone Caro creo que no aparece en ningún manual. Sí aparece algo en la ayuda de Firebird , no recuerdo como lo llama ( tablas derivadas creo).
Ahora bien, estas consultas son TERRIBLEMENTE funcionales, y generalmente TERRIBLEMENTE inificientes en cuanto a velocidad de respuesta, ya que exprimen al motor de base de datos a tope ya que no son 'naturales'. Esto quiere decir que no se utilizan índices ni nada parecido ( generalmente ) y lo que hace el motor es generar una tabla temporal recorriendose las tablas que intervienen de cabo a rabo.
Para confirmarlo es conveniente mirar el plan de ejecución, y además es conveniente medir si es mejor ahorrarse un procedimiento almacenado que cuajar el servidor unos segundos. Sobre todo cuando nuestra base de datos tiene muchos registros.

Casimiro, tus aplicaciones de tropecientos gigas que sueles comentar funcionan estupendamente tanto tiempo y con esos volúmenes porque no conoces estas consultas enrevesadas.
Y que conste, que a mi me gustan , ya que como Caro, me reto a ver si se puede hacer en una sola consulta o no.

Un saludo

[Casimiro Noteví]

Tienes razón, en parte, porque si el servidor es linux y tienes más de una cpu, cuando lanzas la consulta ocupa una de las cpu, pero las demás siguen libres para seguir antendiendo a los restantes usuarios.

He hecho una prueba con una pequeñita, poco más 500 Mb. y efectivamente el primer select lo recorre entero "natural", aunque de todas formas, el tiempo requerido ha sido 1 segundo.

Prepare time: 00:00:00.
Field #01: .CLIENTE Alias:CLIENTE Type:INTEGER
Field #02: .TOTAL Alias:TOTAL Type: DOUBLE PRECISION
PLAN (TBCABECERASFACTURASVENTAS NATURAL)
PLAN (TBCABECERASFACTURASVENTAS ORDER INDCABFACVEN_CLIENTECODIGO)


Executing...
Done.
317488 fetches, 0 marks, 0 reads, 0 writes.
0 inserts, 0 updates, 0 deletes, 62675 index, 62631 seq.
Delta memory: 1184 bytes.
Execute time: 00:00:01.
Script execution finished.

Con otra tabla que tiene más registros (1279329), 2 segundos:

Prepare time: 00:00:00.
Field #01: .CODIGOPEDIDO Alias:CODIGOPEDIDO Type:INTEGER
Field #02: .PRECIO Alias:PRECIO Type: DOUBLE PRECISION
PLAN (TBLINEASALBARANESVENTAS NATURAL)
PLAN (TBLINEASALBARANESVENTAS ORDER RDB$FOREIGN3)


Executing...
Done.
1279329 fetches, 0 marks, 10697 reads, 0 writes.
0 inserts, 0 updates, 0 deletes, 253736 index, 253720 seq.
Delta memory: 1192 bytes.
Execute time: 00:00:02.
Script execution finished.

La prueba la he hecho en mi ordenador personal, ubuntu 8.04 con firebird 2.1 y un AMD athlon 64 x2 dual 4600 con 2 Gb

[rgstuamigo]

Solo comentar que la consulta correcta debería ser con una Union All ya que en realidad segun el requerimiento de Jucho69 es que por cada cliente salga cada importe efectuado más (+) la suma de todos los importe, lo cual significa que la cantidad de registro(tuplas)devueltas en la consulta general deben ser :

Total registros=Cantidad de registro de la primera sub_consulta + Cantidad de registro de la segunda sub_consulta

Quedando la consulta SQL así:

Código SQL [-]
(Select Cliente, Importe From Tabla)   #<-Primera sub_consulta
Union All
(Select Cliente, sum(Importe) as Importe From Tabla Group By Cliente)    #<-Segunda sub_consulta
Order By Cliente,Importe

Quizás los parentesis estan demás pero creo que es mejor ponerlo para una mejor comprensión de lo que se está haciendo..
Saludos...

[Casimiro Noteví]

De esa forma ha sido más rápido incluso, de 2 segundos a 1 seg.

Prepare time: 00:00:00.
Field #01: .CODIGOPEDIDO Alias:CODIGOPEDIDO Type:INTEGER
Field #02: .PRECIO Alias:PRECIO Type: DOUBLE PRECISION
PLAN (TBLINEASALBARANESVENTAS NATURAL)
PLAN (TBLINEASALBARANESVENTAS ORDER RDB$FOREIGN3)


Executing...
Done.
1279329 fetches, 0 marks, 10697 reads, 0 writes.
0 inserts, 0 updates, 0 deletes, 253736 index, 253720 seq.
Delta memory: 1192 bytes.
Execute time: 00:00:01.
Script execution finished.

[Jucho69]

Hola

Gracias a todos por la ayuda, muy atento rgstuamigo, ya creo que contigo habia visto algo parecido, con Union All se pueden enlazar varias consultas previas incluso desde la propia base de datos.

Saludos