Consulta de varios registros y como resultado varias columnas
 

Buenos días,

Disculpen el titulo pero no se como expresarlo :confused:

Tengo la siguiente tabla:

**CODIGO**LECTURA**FECHA**
**001**3400**01/01/2008**
**001**3600**01/02/2008**
**001**3350**31/12/2007**
**002**1500**01/01/2008**
**002**1600**01/02/2008**
**002**1250**31/12/2007**
**003**1000**31/12/2007**
**003**0950**01/11/2007**
**004**1000**01/11/2007**
**004**1250**31/12/2007**

Se necesita hacer una consulta que genere la siguiente salida, suministrando como parametro fecha1 y fecha2:

Parametros:
fecha1: 01/01/2008
fecha2: 01/02/2008

Salida:

**CODIGO**FECHA1(01/01/2008)**FECHA2(01/02/2008)**CONSUMO**
**001**3400**3600**200**
**002**1500**1600**100**

Explicacion:

En el caso del primer codigo (001):

Reg. No. 1: **001**3400**3600**200**

La primera columna: es el codigo que se encuentra en la tabla. (001)
La segunda columna: corresponde a la lectura que coincide con la fecha1. (3400)
La tercera columna: corresponde a la lectura que coincide con la fecha2. (3600)
La cuarta columna: se debe generar la resta de la tercera columna con la segunda columna (3600-3400)=200

De esta manera continua con el codigo (002) y figense que las lecturas con fecha que no estan indicadas, no se muestran en la salida (como lo es el caso de las lectura con fecha: 31/12/2007).

Muchas gracias por su atencion

No estoy demasiado puesto con esos tipos de consultas.... porque la verdad es que nunca practiqué algo así... No se si lo que digo es posible... Creería que se puede conseguir algo así con los componentes de la paleta Decision Cube.

¿Que motor de base de datos usas? Algunos motores soportan la clausula PIVOT que si no me equivoco permite devolver una consulta de dicha forma.

Como dije... no estoy totalmente seguro, pero creo que por allí van los tiros.

Saludos,

objetos
 

Una de las ventajas de sql es que te permite generar varios objetos esto te puede servir

Código SQL [-]
select t1.codigo as codigo ,t1.lectura as fecha1,t2.lectura as fecha2 ,abs(t1.lectura-t2.lectura)as consumo
from tutabla t1 
inner join  tutabla t2 
on t1.codigo=t2.codigo 
where t1.fecha = :fecha1  and t2.fecha = :fecha2

La opción de Delphius es la acertada, sin embargo muestro otras dos opciones más:

- Si tu SGBBDD tiene procedimientos almacenados (SP) puedes construir uno. Siempre y cuando el número de columnas sea fijo y conocido de antemano.

- Usar controles Non data-aware, es decir, un StringGrid y rellenarlo por código delphi.

La consulta base para ambas soluciones sería algo así:

Código SQL [-]
select * from lecturas
where 
(fecha = :fecha1) or (fecha = :fecha2)
order by codigo asc, fecha asc

Consulta
 

Como dijo Delphius la solucion es mejor hacera en un Stored Procedure, en SQL Server seria mas o menos asi:

Código SQL [-]
CREATE PROCEDURE dbo.Test
@FECHA1 DATETIME,
@FECHA2 DATETIME
AS
BEGIN

  SET NOCOUNT ON 
                 
 
SELECT CODIGO,
  SUM(CASE  
  WHEN FECHA = @FECHA1 THEN LECTURA ELSE 0 END) [FECHA1],
  SUM(
  CASE
  WHEN FECHA = @FECHA2 THEN LECTURA ELSE 0 END) [FECHA2]
  FROM #LECTURA 
  WHERE FECHA = @FECHA1 OR FECHA=@FECHA2
  GROUP BY CODIGO 
  
END

Ya la resta del consumo la puedes hacer en un campo calculado

Saludos

My bien a se tiene que replanear
 

Ok, muchas gracias a todos, pero se necesita replantear el problema de la siguiente manera:

Tabla "suscriptores" y los campos son: "id_suscriptor", "nombre_fiscal"

Datos:
**id_suscriptor**nombre_fiscal**
**001**viveres los primeros**
**002**Ferretería vieja**
**003**El mejor de todos**
**004**Gabriel Garcia**

Tabla "direccion_operacional" y los campos son: "codigo_do","direccion_operacional", "ruta", "id_suscriptor"

Datos:
**codigo_do**direccion_operacional**ruta**id_suscriptor**
**5000**Av. 5 con calle 13**1**001
**5010**Ciudad del Cabo**2**002
**6000**Calle cinco No. 1**3**003
**6010**Av. 1. con calle 14**4**001

Tabla "lecturas" y los campos son: "codigo_do", "lectura", "fecha"

Datos:
**codigo_do**lectura**fecha**
**001**3400**01/01/2008**
**001**3600**01/02/2008**
**001**3350**31/12/2007**
**002**1500**01/01/2008**
**002**1600**01/02/2008**
**002**1250**31/12/2007**
**003**1000**01/01/2008**
**003**0950**01/02/2008**
**003**0951**31/12/2007**
**004**1000**01/01/2008**
**004**1250**01/02/2008**
**004**1251**31/12/2007**



La consulta que se necesita es la que se definio como salida en el primer comentario. Ahora bien, haciendo la reestructuracion, se necesita leer todo la tabla de direccion_operacional con los mismo parámetros, buscar el nombre fiscal y saber las lecturas en la tabla de lecturas y la salida seria de la siguiente manera:

**ruta**codigo_do**nombre_fiscal**direccion_operacional**fecha1(01/01/2008)**fecha2(01/02/2008)**consumo**
**1**5000**viveres los primeros** Av. 5 con calle 13**3400**3600**200
**2**5010**Ferretería vieja**Ciudad del Cabo**1500**1600**100**
**3**6000**EL mejor de todos**Calle cinco No.1 **1000**1950**950**
**4**6010**Gabriel Garcia**Av. 1 con calle 14**1000*1250**250**


Gracias por la colaboracion prestada y el apoyo

Buenos dias, la solucion del amigo espericueta funciono perfectamente sobre la tabla de lecturas pero muy sencillamente, solo necesito hacer los cambios para incorporar las otras tablas, pero en eso estamos. Gracias por la atencion de todos.....:)

Que bien que te funciono , no habia visto tu problema replanteado quizas asi te sirva o mas o menos por ahi va :

Código SQL [-]
select 
d.ruta as Ruta,d.codigo_do,s.nombre_fiscal,
d.direccion_operacional,l1.fecha1,l2.fecha2,(l1.lectura-l2.lectura) as Consumo  
from 
Direccion_operacional d 
left outer join suscriptores s 
on s.id_suscriptor= d.codigo_do
left outer join lectulas l1
on l1.codigo_do=d.codigo_do
left outer join lecturas l2
on l2.codigo_do=d.codigo
where l1.fecha= :fecha1 and l2.fecha= :fecha2

Saludos !!!

Ok, buenas noches,

Se realizaron algunas modificaciones con la sugerencia del ultimo post (espericueta)y quedo de la siguiente manera:


Código SQL [-]
select
d.ruta as RUTA,d.codigo_do as CODIGO_DO,sus.nombre_fiscal as NOMBRE,
d.descripcion as DIRECCION, t1.lectura, t2.lectura, (t1.lectura-t2.lectura) as Consumo, t1.fecha, t2.fecha
from Direccion_operacional d
left outer join suscriptores sus on sus.id = d.id_suscriptor
left outer join lecturas t1 on t1.codigo_do=d.codigo_do
left outer join lecturas t2 on t2.codigo_do=d.codigo_do
where (t1.fecha= :fecha1 and t2.fecha= :fecha2) and (d.tipo_tarifa=:tarifa) and (d.ruta>=:ruta1 and d.ruta<=:ruta2)





Cabe destacar que cuando se le da un rango a la ruta entre 1 y 50, dicha consulta dura demasiado tiempo (mas de 30 minutos).

La cantidad de registro por cada tabla es la siguiente:

tabla: DIRECCION_OPERACIONAL
Numero de Registros: 4632

Tabla: LECTURAS
Numero de Registros: 775856

Tabla: SUSCRIPTORES
Numero de Registros: 4424

Realmente no consigo acelerar este procedimiento. Gracias por su atencion.

El motivo de la lentitud de dicha consulta puede deberse a una condición de estos factores:
1. Joins. Demasiados joins anidados y consultas de agrupación demoran más tiempo que otras sentencias.
2. Una mala aplicación de índices. Los campos con los que trabaja la consulta tienen índices. Crear indices para algunos de dichos campos acela las consultas.

Me parece raro que demore tanto tiempo, analiza estos factores (sobre todo el segundo) No son demasiados los registros como para que se demore tanto... otro factor que se me ocurre (aunque improbable) es que sea el equipo hardware que no posee la suficiente capacidad de memoria/procesamiento para proceder con la consulta.

Por el momento más no se me ocurre.
Saludos,

Buenos dias, de momento no tengo creado ningun tipo de indice, voy a trabajar con eso ya que nunca lo he hecho y luego escribo los comentarios. Gracias por tu atencion. Si tienen alguna sugerencia, les agradezco. De antemano muchas gracias.....

Seguro de esto ?, recuerda que cada clave primaria de tu tabla es un indice, y que los join generalmente se hacen a través de estos precisamente para acelerar la velocidad de consultas y por un tema de base de datos relacionadas.

Hasta Luego .-

Buenos dias,

Primero que nada quiero agradacer a todas las personas que regalaron una pequeña parte de su valioso tiempo. Y segundo la conclusion en que se llegó por nuestra parte a la solucion de esta situación, fue una de las recomendaciones hechas por Delphius, el cual consistió en la creación acertada de los índices para las tablas utilizadas en dicha consulta, dando como resultado la disminución escandalosa en el tiempo de resupuesta a menos de 5 segundos, por lo tanto la situación planteada incialmente queda resuelta.

Muchas gracias....:)