[Gfoss] Splite - Unione tabelle

[a.furieri a lqt.it]

On Tue, 25 Mar 2014 13:52:33 +0100, pierluigi de rosa wrote:
> Ciao a tutti.
> Sto cercando di fare una cosa con splite ma non ho trovato ancora la
> soluzione.
> Ho un db che contiene dei layer-tavole esattamente uguali nella
> struttura e nelle geometrie.
> Vorrei creare una vista geometrica che me li vede tutti insieme
> automaticamente. Ovvero vorrei evitare di dare il nome delle tavole 
> ma
> che li leggesse da una metatabella che contiene i layer presenti nel
> db.
> Il tutto perché ho necessità di aggiungere layer al db nel corso del
> tempo ma mi serve una vista in grado di visualizzare tutti i layer
> come un unico strato informativo.
>

Ciao Pierluigi,

la prima parte del quesito e' molto facile da risolvere:

CREATE VIEW mescolone AS
SELECT "tavola1" AS origine, pippo AS a,
   pluto AS b, topolino AS c, geometry
FROM tavola1
UNION
SELECT "tavola2" AS origine, qui AS a,
   quo AS b, qua AS c, geometry
FROM tavola2
UNION
SELECT "tavola3" AS origine, alfa AS a,
   beta AS b, gamma AS c, geometry
FROM tavola3;

la seconda parte (cioe' pescare dinamicamente i nomi-tavola
da una metabella) direi che e' assolutamente fuori portata
di qualsiasi possibile implementazione "puro SQL".
eventualmente potresti pero' appoggiarti su qualche linguaggio
(p.es. python) per implemetare un piccolo script che:
- cancelli la versione precedente della vista
- ricostruisca ex-novo il codice di creazione della VIEW
   tutte le volte che cambi la meta-configurazione.
- ed infine vada a crearsi la nuova versione della VIEW


Avvertenze e precauzioni:
-------------------------
- aggiungere una colonna extra che tracci le origini in
   genere risulta abbastanza utile e comodo.
- la UNION elimina implicitamente tutti i doppioni; se
   vuoi essere sicuro di non perdere nessuna riga allora
   usa piuttosto la UNION ALL
- se stimi che le tue tavole cresceranno fino ad avere
   dimensioni pesantucce (milioni di righe) ti consiglio
   di comprarti una buona scorta di libri gialli, film
   divertenti e tanta buona musica .... perche' ogni volta
   che andrai a lanciare una query su quella View potrebbe
   anche impiegare tempi decisamente molte lunghi prima di
   decidersi a sfornare qualche risposta.

CAVEAT e contro-indicazioni:
----------------------------
- con una VIEW di questo tipo (basata su piu' tavole) perdi
   automaticamente qualsiasi possibilita' di utilizzare gli
   Spatial Index (il che contribuira' ulteriormente ad
   assicurare prestazioni sicuramente pessime).
- inoltre scordati di riuscire mai a leggere una View di
   questo tipo p.es. su QGIS, perche' uno dei requisiti
   imposti dal data-provider e' che la colonna geometrica
   della View sia direttamente riconducibile ad una singola
   colonna registrata in "geometry_columns"


Suggerimenti:
-------------
personalmente eviterei accuratamente di utilizzare le
View e peggio che peggio le Union (due bellissimi
meccanismi formali, molto stuzzicanti perche' danno
l'illusione apparente di risparmiare storage evitando
qualsiasi ridondanza, ma anche due performance-killer
di spaventosa efficienza).

preferirei piuttosto crearmi un unico "tavolone",
magari con una colonna extra utile per tracciare le
origini, e con un robusto Spatial Index di supporto
per garantire alta velocita' di elaborazione.

insomma, invertirei totalmente i termini del problema;
un unico layer monolitico, che ti assicura certamente
il top dell'efficienza e dell'uso ottimizzato dello
storage.
e che contemporaneamente ti continua a dare la possibilita'
di recuperare a piacere ciascun singolo sub-layer visto
che le origini verranno sempre scrupolosamente tracciate:
bastera' una banale query "... WHERE origine = 'pippo' ..."
per spacchettare a ritroso ciascuno dei layers elementari
qulora dovesse servire.

ciao Sandro