Splite - Unione tabelle

[pierluigi de rosa-2]

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.
 Grazie
Pierluigi

Term. Mobile
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013

[a.furieri]

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


_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013

[a.furieri]

On Tue, 25 Mar 2014 14:28:31 +0100, [hidden email] wrote:

> 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.
>

ho dimenticato di aggiungere ...

naturalmente potresti poi implementare in modo certamente
efficiente tante Views corrispondenti a ciascun singolo
sub-layer, del tipo:

CREATE VIEW vista_1 AS
SELECT ROWID as ROWID, a AS a, b AS b,
   c AS c, geometry AS geometry
FROM mescolone
WHERE origine = 'tavola1';

CREATE VIEW vista_2 AS
SELECT ROWID as ROWID, a AS a, b AS b,
   c AS c, geometry AS geometry
FROM mescolone
WHERE origine = 'tavola2';

... and so on ....

Views di questo tipo continuano pur sempre a supportarti
efficientemente lo Spatial index, e sono perfettamente
compatibili con i requisiti del data-provider di QGIS

naturalmente, in questo caso creare un indice di ricerca
sulla colonna "origine" e' decisamente raccomandabile:

CREATE idx_origine_mescolone ON mescolone (origine);

ciao Sandro


_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013

[pcav]

Il 25/03/2014 14:28, [hidden email] ha scritto:

> - 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"

Sei sicuro di questo?
Saluti.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013

[a.furieri]

On Tue, 25 Mar 2014 14:42:35 +0100, Paolo Cavallini wrote:

> Il 25/03/2014 14:28, [hidden email] ha scritto:
>
>> - 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"
>
> Sei sicuro di questo?
>

assolutamente si: perche' altrimenti non saprebbe proprio
dove andare a sbattere la testa per riuscire a capire
quale e' lo spatial index da interrogare.

recall: su sqlite/splite lo Spatial Index e' semplicemente
una ulteriore tavola indipendente e del tutto a se stante,
che richiede una inner sub-query esplicita per potere
essere interrogata.
e quindi al data-provider serve assolutamente accedere a
"geometry_columns" per verificare se un R*Tree risulta
realmente definito, e quindi poi ricavare il nome-tavola
da inserire nela sub-query.

ciao Sandro
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013

[pcav]

Il 25/03/2014 14:48, [hidden email] ha scritto:

> assolutamente si: perche' altrimenti non saprebbe proprio
> dove andare a sbattere la testa per riuscire a capire
> quale e' lo spatial index da interrogare.

chiedevo, visto che in PostGIS non e' cosi'.
Saluti, e grazie del chiarimento.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013