¡Ahora sí estamos hablando cosas concretas!
Bueno, supongamos que tomamos la consulta final, y le queremos agregar allí dos columnas al final, que en realidad tendrán datos en cero. Son columnas virtuales, porque no existen en realidad, pero las "fabricamos" para el resultado de la consulta:
Código SQL:
Ver originalSELECT
item,
V.codigo codigovolcan,
V.nombre nombrevolcan,
V.alias,
codigo_observatorio,
TE.codigo codigotipoestacion,
TE.nombre nombreestacion,
A.nombre nombrearea,
A.codigo codigoarea,
0 TotalTelem,
0 TotalNoTelem
FROM
volcan V
INNER JOIN inv_est_instaladas IEI ON V.codigo = IEI.codigo_volcan
INNER JOIN conectividad_inv_estaciones CIE ON IEI.item = CIE.item_inv_est_instaladas
INNER JOIN tipo_estacion TE ON IEI.codigo_tipo_estacion = TE.codigo
INNER JOIN area A ON TE.codigo_area = A.codigo
WHERE
V.código_observatorio = 'ovsm'
AND TE.suma = 't'
AND CIE.item_conectividad = 1
ORDER BY
A.codigo,
TE.codigo,
V.codigo
He aprovechado para corregir un poco el orden de las tablas y agregarle los
alias que simplifican la escritura, así como quitares los "AS" que actualmente son obsoletos y no generan nada.
Les he puesto INNER JOIN en lugar de la coma, porque el parser está optimizado para hacerlo mejor al realizar ese filtrado en el FROM y no en el WHERE. Lamentablemente los manuales insisten en usar la coma, que es francamente un desastre de performance llegado el momento de consultas masivas.
Bueno, ese sería el esquema que yo usaría para la consulta. De ese modo la cantidad de columnas de la tabla de datos devuelta coincidiría con la cantidad de columnas a representar en la pantalla.
Incluso se puede llegar más lejos y crear datos sumando valores en esas columnas dentro de la consulta, o bien poner los alias de las columnas que realmente usarán en la salida de datos al usuario, y simplemente recorrer tanto los encabezados como los datos al momento de representarlo.... pero eso te lo dejo a ti...