Si, intendo proprio quella, comunque serve un trigger sulla tabella originaria per ordinare il lancio del refresh della vista materializzata stessa. La logica sarebbe sempre la stessa, inoltre una vista materializzata non รจ altro che una particolare tabella che memorizza, oltre ai dati generati dalla query, anche la query utilizzata per generarla (le prestazioni sarebbero le stesse di una tabella normale).

Se vuoi usare PostGIS si potrebbe seguire questa strada, ovviamente se serve un database enterprise nel tuo progetto.


Il 13/12/2017 17:47, Massimiliano Moraca ha scritto:
Intendi questa: https://www.postgresql.org/docs/9.6/static/rules-materializedviews.html

Il giorno 13 dicembre 2017 17:41, Marco Li Volsi <marco.livo...@gmail.com <mailto:marco.livo...@gmail.com>> ha scritto:

    metto un po' di carne al fuoco... ma usare le Materialized View in
    PostgreSQL ?



    Il 13/12/2017 17:35, a.furi...@lqt.it <mailto:a.furi...@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
        <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
        _______________________________________________
        Gfoss@lists.gfoss.it <mailto:Gfoss@lists.gfoss.it>
        http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
        <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.
        801 iscritti al 19/07/2017


    _______________________________________________
    Gfoss@lists.gfoss.it <mailto:Gfoss@lists.gfoss.it>
    http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
    <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.
    801 iscritti al 19/07/2017



_______________________________________________
Gfoss@lists.gfoss.it
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.
801 iscritti al 19/07/2017

Reply via email to