[Gfoss] storicizzare le tabelle con il plugin di qgis: Postgis Manager (funziona molto bene!)

[unknown]

a seguito del post* "storicizzazione** dell*e modifiche in postgres/postgis"

ho fatto alcune prove con il plugin di Qgis "Postgis Manager"
per vedere se riuscivo a storicizzare le modifiche in una tabella del db

devo dire che il plugin soddisfa pienamente l'esigenza!!
inoltre fa anche moltre altre cose... per esempio Ú possibile aggiungere un
trigger per il calcolo automatico dell'area dell'oggetto ad ogni modifica
geometrica!

tornando alla funzione di storicizzazione...
si attiva dal menu DATA -> TABLE VERSIONING
selezioni schema e tabella
e poi
nella tabella vengono create 3 colonne:
- id_hist (che sostituirà la gid)
- time_start
- time_end

viene inoltre creata una vista con la versione corrente della tabella

ho avuto qualche problemino all'inizio durante le prove di modifica del
layer:
la prima modifica fatta su ogni riga del DB
non valorizzava il campo time_end della riga da invalidare (old)
e così ci si trovava con due record validi uguali...

ci ho messo un po' a capire che dipendeva dal fatto che la colonna
time_start era vuota!
così ho risolto in questo modo:
- ho disabilitato il trigger dell'update
- ho valorizzato la colonna time_start
- ho riattivato il trigger

con questo plugin, senza avere conoscenze di programmazione di postgres
si può organizzare un buon sistema di storicizzazione di dati geografici

una possibile miglioria del plugin:
per tenere traccia di chi fa le modifiche
sarebbe da aggiungere 2 colonne: utente_start e utente_end

ciao!

emanuele masiero
padova
-------------- parte successiva --------------
Un allegato HTML ￜ stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20110702/42235fba/attachment.html>

[unknown]

Post by unknown
devo dire che il plugin soddisfa pienamente l'esigenza!!

Bene!

Post by unknown
per tenere traccia di chi fa le modifiche
sarebbe da aggiungere 2 colonne: utente_start e utente_end

Puoi aprire dei tickets (wishes), cosi' non ce lo dimentichiamo?
Grazie.

[unknown]

Post by unknown

Post by unknown
devo dire che il plugin soddisfa pienamente l'esigenza!!

Bene!

Post by unknown
per tenere traccia di chi fa le modifiche
sarebbe da aggiungere 2 colonne: utente_start e utente_end

Puoi aprire dei tickets (wishes), cosi' non ce lo dimentichiamo?
Grazie.

Anche sqlite/spatialite supporta i triggers.
Potrebbe essere fattibile una cosa del genere su spatialite ?

Andrea.

[unknown]

Post by unknown
Anche sqlite/spatialite supporta i triggers.
Potrebbe essere fattibile una cosa del genere su spatialite ?

L'idea e' quella di generalizzare il manager, in modo da avere le stesse
funzionalita' per tutti i db, in modo trasparente. Giuseppe Sucameli sta lavorando su
questo, grazie ad un Google summer of code.
Saluti.

[unknown]

Post by unknown
Anche sqlite/spatialite supporta i triggers.
Potrebbe essere fattibile una cosa del genere su spatialite ?

L'idea e' quella di generalizzare il manager, in modo da avere le >stesse
funzionalita' per tutti i db, in modo trasparente. Giuseppe Sucameli
sta lavorando su
questo, grazie ad un Google summer of code.
Saluti.

Accidenti.
Non e' affatto semplice.

Anche se immagino che quando parli di DB intendi proprio i dbms e non
gli shapefile, dxf, csv e roba analoga.

Resta comunque una buona notizia.

Colgo l'occasione per fornire uno spunto di riflessione che potrebbe
essere utile a Giuseppe.

Da quello che capisco dalla descrizione, qui la geometria storicizzata
resta nella medesima tabella.

Io personalmente darei la mia preferenza a meccanismi basati su tabelle
di storicizzazione distinte.

Certamente questa soluzione di avere tutto in una unica tabella rende
piu' facile la query di selezione per data, pero' diviene piu'
complicato gestire i legami di foreign-key con altre tabelle.

Per cui una storicizzazione basata sulla medesima tabella costringe a
progettare un DB spaziale senza esplicitare dei vincoli di foreign-key.
Oppure, si impone che anche le modifiche apportate rispettino tutti i
legami di FK.
Questo però incrementa in maniera non trascurabile la complessità di
gestione.

Andrea.

[unknown]

Post by unknown

Post by unknown
per tenere traccia di chi fa le modifiche
sarebbe da aggiungere 2 colonne: utente_start e utente_end

Puoi aprire dei tickets (wishes), cosi' non ce lo dimentichiamo?

fatto!

Colgo l'occasione per fornire uno spunto di riflessione che potrebbe essere

Post by unknown
utile a Giuseppe.
Da quello che capisco dalla descrizione, qui la geometria storicizzata
resta nella medesima tabella.
Io personalmente darei la mia preferenza a meccanismi basati su tabelle di
storicizzazione distinte.

anche secondo me la gestione dello storico in una tabella separata sarebbe
ottimale!!!


ciao
emanuele masiero
padova
-------------- parte successiva --------------
Un allegato HTML ￜ stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20110703/1e1a421b/attachment.html>