Grazie per le indicazioni a tutti e due :)
Il giorno 15 dicembre 2017 08:02, Andrea Peri <aperi2...@gmail.com> ha
scritto:
>
> 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
