>> 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.
_______________________________________________
Iscriviti all'associazione GFOSS.it:
http://www.gfoss.it/drupal/iscrizione[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfossQuesta e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
518 iscritti al 3.6.2011
Locked
