[Gfoss] ST_Union e PostGIS

[Massimiliano Moraca]

Da premettere che non ho usato(ancora) nessun plugin o tool di QGIS per
manipolare il db.

I TRIGGER (di cui so 0!) potrebbero ovviare alla creazione delle view? Mi
spiego meglio. Mi sono rassegnato, per ora, a creare le tabelle e non le
view: un trigger potrebbe fare in modo che aggiornata la tabella
principale(ammesso si possa fare questo distinguo) si attivi
automaticamente l'aggiornamento di quella "correlata" all'area aggiornata?

Come ho scritto stavo provando con i filtri di QGIS, ma forse Sandro quando
parlavi dell'approccio ingannevole di QGIS ti riferivi a questo?

Non ho una grande esperienza in SQL e ci sono cose avanzate, come i
TRIGGER, che mi sono ignote....

Il giorno 13 dicembre 2017 17:35, <a.furieri a lqt.it> ha scritto:

> On Wed, 13 Dec 2017 17:05:43 +0100, Sandro Santilli wrote:
>
>> On Wed, Dec 13, 2017 at 04:38:22PM +0100, Massimiliano Moraca wrote:
>>
>>> Tra l'altro noto che le VIEW rendono il caricamento dei dati in QGIS un
>>> processo molto lento, cosa che non avviene nelle table.
>>>
>>
>> Perche' non puo' usare un indice su un oggetto che non esiste ancora
>> fino al momento della SELECT, immagino. Se la materializzi, e ci
>> definisci un indice, dovresti risolvere. Per l'aggiornamento
>> "automatico" potresti usare dei trigger (almeno in PostGIS, non so
>> in Spatialite).
>>
>>
> Strk,
>
> mi hai letto nel pensiero ;-)
> SQLite offre un supporto molto efficiente per i Triggers.
>
> [1] https://www.sqlite.org/lang_createtrigger.html
>
> Se Massimiliano se la sente non sarebbe per nulla difficile
> aggiornare automaticamente la tavola aggregata ogni volta
> che viene modificata la tavola madre.
>
> ok, richiederebbe la scrittura di un po' di codice SQL a
> supporto di qualche Trigger da impiantare da zero.
> ma alla fine otterebbe qualcosa di sicuramente piu' efficiente
> e robusto di quel che puo' ottenere automaticamente dai vari
> tool di QGIS basati sulle improbabili Spatial Views "updatable"
> che sono semplicemente un tentativo decisamente estremo per
> cercare di nascondere "sotto al cofano" tutte le numerose
> differenze di architettura che ci sono tra PostgreSQL e
> SQLite.
>
> ciao Sandro
>