Ad esempio un esempio di uso che ho tipico di un trigger e' impedire la
modifica dei dati.
Ricordo un vecchio nostro plugin che facemmo realizzare per qgis in cui la
base dati era uno spatialite nelle cui tabelle erano stati inseriti dei
triggers per impedire che l'utente potesse
modificare i dati aprendo un qgis e mettendo lo spatialite in editing. Il
plugin guidava l'utente a eseguire detemrinate modifiche in un certo modo e
solo quelle.
Volevamo garantirci che l'utente non potesse aprire lo spatialite in
autonomia con qgis stesso o con altro software e intervenire sui dati
alterandoli in maniera incontrollata.
Per questo adottammo alcuni triggers che a certe condizioni impedivano la
modifica dei dati.
Altro esempio e' quello di usare un triger per fare la MakeValid della
geometria e garantire quindi la sua correttezza.
Tutto bello.
Pero' attenzione ad aggiungere i triggers.
Il maggior rischio e' pensare di usarli per fare cose troppo sofisticate.
Con il rischio che poiche' non si a mai cosa in futuro ci si deve fare con
tali dati, di ritrovarsi magari dopo qualche mese a vedere comportamenti
anomali su un applicativo e dimenticarsi che dentro la BD vi' sono dei
triggers che facevano certe operazioni e che guarda caso interfericono con
altre operazioni all'epoca non preventivate.
I triggers non sono facilmente rilevabili , e, specialmente su spatialite,
non credo che si possano nemmeno rimuovere senza interferire con i dati
stessi.
Qui pero' forse lo sa' meglio Furieri.
Forse mi sbaglio, ma temo che per rimuovere un trigger su una tabella
spatialite sia necessario droppare la tabella con tutto il suo contenuto.
Se cosi' fosse occorre stare parecchio attenti a usarli , perche' se per
rimuovere un trigger che da noia si deve cancellare tutti i dati in tale
tabella.
Si fa' certamente, ma diventa macchinoso e complicato .
Quindi attenzione, massima attenzione a usare i triggers.
A.
Il giorno 15 dicembre 2017 00:40, <a.furi...@lqt.it> ha scritto:
> On Thu, 14 Dec 2017 22:19:25 +0100, Massimiliano Moraca wrote:
>
>> Sti trigger mi stanno inTRIGGando :P
>> Con un trigger è possibile anche tenere traccia dell'evoluzione
>> temporale di un vettore? Ad esempio poligoni creati, modificati,
>> cancellati..?
>>
>>
> Massimiliano,
>
> certo che puoi; i triggers sono un meccanismo universale,
> ci puoi fare qualsiasi cosa che ti viene in mente
> (o quasi ...)
>
> l'unico limite e' la tua capacita' creativa di saperti
> "inventare" un buon modello dati; naturalmente serve
> anche una base molto solida di conoscenza teorica su
> SQL con tutte le sue estensioni Spatial, cosi' come e'
> indispensabile quella certa "praticaccia spicciola" che
> si acquisisce solo a forza di lavorare sul campo imparando
> piu' che altro dai propri errori.
>
> giusto per analizzare per sommi capi il tuo esempio
> relativo all'evoluzione storica dei dati, e' molto
> piu' semplice di quanto tu possa credere:
>
> 1. ti crei una tavola di appoggio in cui andrai a
> registrare tutte le successive modifiche delle
> tue geometrie. una scelta saggia sarebbe quella
> di introdurre un opportuno vincolo FK che associ
> direttamente ciascuna "riga-versione" con la
> corrispondente riga della tavola-madre.
> cosi' come sarebbe opportuno inserire un timestamp
> che tenga traccia della data-ora in cui e' avvenuta
> la modifica; datti un'occhiata a DateTime('now')
>
> 2. a questo punto vai ad installare tre triggers
> sulla tavola-madre, uno per la Insert, uno per
> la Update ed uno per la Delete.
> ovviamente ciascuno di questi non fara' altro
> che prendere la geometria e salvarla permanentemente
> sulla tavola-versioni associandola al timestamp
> corrente.
>
> basta; non serve altro. e' piu' facile da implementare
> che da spiegare.
>
>
> concetti da tenere bene a mente:
> ================================
> un Trigger e' semplicemente un gestore di eventi.
> una volta che il Trigger e' correttamente installato
> scattera' automaticamente tutte le volte che si
> verifica l'evento in oggetto.
> l'azione specifica di ciascun Trigger e' determinata
> da un "pezzo" di SQL che sta a te scrivere nel modo
> che ritieni piu' opportuno; hai tutta la liberta'
> che vuoi di fare qualsiasi cosa che ti passi per la
> zucca, basta solo che tu trovi il modo di tradurla
> in una appropriata sequenza di comandi SQL.
> ovviamente liberta' e responsabilita' sono sempre
> due facce della medesima medaglia; se non funziona
> e' sicuramente colpa tua, e ti dovrai quindi armare
> di santissima pazienza per fare tutto il debugging
> del caso (che e' poi la vera essenza di qualsiasi
> sviluppo sw; un bravo sviluppatore non e' uno bravo
> a scrivere codice, e' soprattutto uno bravo a fare
> debugging)
>
>
> Mi indicate una risorsa da cui studiare? Anche un libro se non c'è
>> nulla online...
>>
>>
> non credo proprio che esista nulla di specifico
> relativo ai triggers, al massimo puoi trovare qualche
> manuale generico su SQL che avra' un capitoletto
> sui meccanismi generali dei triggers.
> dovresti sicuramente trovare qualche manuale piu' o
> meno ponderoso in qualsiasi libreria universitaria.
>
> per tutto il resto serve tenere sempre sotto mano
> la doc tecnica del tuo DBMS preferito [1], ma soprattutto
> servono tempo, pazienza e perseveranza, uniti ad un
> pizzico di intuizione e di fantasia creativa.
>
> [1] https://www.sqlite.org/lang.html
>
> ciao Sandro
>
>
>
> _______________________________________________
> 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
>
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
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
