[Gfoss] R: Re: Re: Re: Un'altra questione su PG
Andrea Peri
aperi2007 a gmail.com
Lun 20 Lug 2015 11:45:14 CEST
Non conosco il progetto che citi.
Pero Come to ha detto anche Fadini.
La vista può essere il tul vero output.
Per cui alla fine restituisci un dato esposto dalla vista che conterrà la
somma ipotetica.
Il 20/lug/2015 10:40 AM, "Alessandro Ciali" <alessandro.ciali a gmail.com> ha
scritto:
> Intanto grazie per la query, il ptoblema era proprio quello, ora tutto
> funziona.
> Per la qustione della struttura del db, concordo al 100% ma purtoppo devo
> riprodurre lo schema di archiviazione deciso per le indagini di
> microzonazione sismica regionale toscana e nazionale qui di sono obbligato
> a rispettare questa struttura....
>
>
> Inviato da Samsung Mobile.
>
>
> -------- Messaggio originale --------
> Da: Andrea Peri
> Data:20/07/2015 00:09 (GMT+01:00)
> A: Alessandro Ciali
> Cc: gfoss a lists.gfoss.it
> Oggetto: Re: Re: Re: [Gfoss] Un'altra questione su PG
>
> >mi son messo in testa di creare una banca dati il più possibile
> indipendente dal programma che poi la utilizza
>
> Non ho idea di come sia possibile arrivare a una base dati che sia
> indipendente dal programma che la utilizza, ma occorre capirsi sul
> concetto di indipendenza.
>
> Se il tuo obiettivo e' avere una base dati di data entry devi
> minimizzare gli inserimenti, ma anche devi focalizzarti sulla
> informazione atomica, evitando di perdere tempo nella informazione
> ridondante. he sarebbe quella ricavabile da elaborazione (o
> informazione ricavabile), la quale non è vera informazione perche' e'
> sempre ricavabile alla bisogna.
>
> Se te progetti una banca dati che sia composta di 2 valori
> indipendenti e poi prevedi un terzo campo che contenga la somma degli
> altri due.
> La vera base dati e' composta dai 2 campi iniziali, il terzo non porta
> informazione perche' e' ricavabile dagli altri due.
>
> Quindi un trigger che faccia le somme non serve per avere una base
> dati indipendente, perche' la vera banca dati indipendnete e' composta
> dai due campi. Il terzo e' una derivazione dei primi due per somma e
> quindi non è un valore indipendente.
>
> Io non ho chiaro cosa stai cercando di fare, e cosa siano quei punti
> che vuoi mettere in relazione con la am_com.
> Ma io , piuttosto che farli calcolare a un trigger e archiviarli
> hardcoded nella tabella, li esporrei tramite una vista che esprima la
> query sql che stai cercando di fa calcolare al trigger.
>
>
> A.
>
> Il 19 luglio 2015 22:57, Alessandro Ciali <alessandro.ciali a gmail.com>
> ha scritto:
> >
> > Questa tua mail è per me molto interessante. Innanzitutto grazie per il
> > suggerimento, provvederò a provare omettendo la tabella puntuale nella
> > query. Riguardo la scelta di utilizzare regole di autocompilazione
> > direttamente in Pg deriva dal fatto che, da profano, mi son messo in
> testa
> > di creare una banca dati il più possibile indipendente dal programma
> che
> > poi la utilizza; in qgis ho semplicemente messo in grigio i campi che non
> > hanno bisogno di input da parte dell'utente. Pensi che sia un approccio
> > sbagliato?
> >
> > Inviato da Samsung Mobile.
> >
> >
> > -------- Messaggio originale --------
> > Da: Andrea Peri
> > Data:19/07/2015 21:02 (GMT+01:00)
> > A: Alessandro Ciali
> > Cc: Luca Lanteri , gfoss a lists.gfoss.it
> > Oggetto: Re: Re: [Gfoss] Un'altra questione su PG
> >
> > SInceramente non uso mai i triggers.
> > Li trovo pochissimo pratici per queste attivita'.
> >
> > Trovo un po' fuori contesto usare dei triggers per una attivita' di
> > correzione o inserimento dati.
> > Queste cose dovrebbero essere esplicitate in azioni da parte dell'utente.
> > Altrimenti uno si vede cambiare un db sotto i piedi e non capisce
> perche'.
> >
> > Comunque padronissimo di usarlo come credi meglio ovviamente.
> > :)
> >
> > Venendo al tuo caso:
> >
> > a me sembra che la tua query sia destinata sia ridondante rispetto a
> > cio' che filtra.
> >
> > perche' ST:Within($1, c.geom)
> > interseca la geometria che gli passa il trigger con la geoemtria di
> am_com.
> > Da li' probabilmente ne ritornerebbe 1 sola.
> >
> > Ma nella query te metti anche
> > La tabella
> > ,indagini."Sito_Puntuale" AS s
> >
> > senza isnerirla in una regola di filtro.
> > Per cui ti provoca un prodotto cartesiano e ti moltiplica i records
> > per molte volte.
> >
> >
> > Non so' se si sono altri problemi, ma questo secondo me non va bene.
> >
> > A.
> >
> >
> > Il 19 luglio 2015 19:29, Alessandro Ciali <alessandro.ciali a gmail.com>
> > ha scritto:
> >>
> >> Si, ma una query di update non mi permette di Popolare i campi via via
> che
> >> creo dei siti puntuali. Dovrei prima inserire i punti, salvare la
> tabella
> >> e
> >> poi far girare la query, che inoltre dovrebbe essere lanciata ogni volta
> >> cche finisce la fase di editing, mentre un trigger parte tutte le volte
> >> che
> >> una riga viene salvata
> >>
> >> Inviato da Samsung Mobile.
> >>
> >>
> >> -------- Messaggio originale --------
> >> Da: Andrea Peri
> >> Data:19/07/2015 18:49 (GMT+01:00)
> >> A: alessandro.ciali a gmail.com
> >> Cc: Luca Lanteri , "GFOSS.it"
> >> Oggetto: Re: [Gfoss] Un'altra questione su PG
> >>
> >> Per quale ragioni fai uso di un trigger anziche' una query di update ?
> >>
> >>
> >> Il 19 luglio 2015 18:02, <alessandro.ciali a gmail.com> ha scritto:
> >>> Ciao a tutti,
> >>> mi sono arenato su un problema cui non riesco a trovare una soluzione…
> >>> Vorrei estrarre alcuni dati da una copertura e passarli ai campi di una
> >>> tabella puntuale, in base alla posizione di nuovi punti che inserisco,
> >>> ossia nel caso specifico passare il codice provincia e comune ai nuovi
> >>> punti
> >>> inseriti in una tabella “sito_puntuale”. I dati comune e provincia sono
> >>> su
> >>> una tabella spaziale “am_com”. Il tutto è in un database PGsql.
> >>> Come in precedenza pensavo di risolvere il problema con un trigger, e
> >>> quindi
> >>> ho creato la seguente funzione sfruttando ST_Wtithin di postgis:
> >>>
> >>> CREATE OR REPLACE FUNCTION indagini.cal_idn()
> >>> RETURNS trigger AS
> >>> $BODY$DECLARE
> >>> cod character(6);
> >>> BEGIN
> >>> -- codcom da public.am_com
> >>> cod = codcom FROM public.am_com AS c,indagini."Sito_Puntuale" AS s
> WHERE
> >>> (ST_Within(NEW.the_geom,c.geom));
> >>> -- calcola ubicazione_prov e ubicazione_com
> >>> NEW.ubicazione_prov = substr(cod, 1, 3);
> >>> NEW.ubicazione_com = substr(cod, 4, 3);
> >>> RETURN NEW;
> >>> END;
> >>> $BODY$
> >>> LANGUAGE plpgsql VOLATILE
> >>> COST 100;
> >>> ALTER FUNCTION indagini.cal_idn()
> >>> OWNER TO postgres;
> >>> GRANT EXECUTE ON FUNCTION indagini.cal_idn() TO public;
> >>> GRANT EXECUTE ON FUNCTION indagini.cal_idn() TO postgres;
> >>>
> >>> Purtroppo quando però vado a salvare mi viene restituito il seguente
> >>> messaggio di errore:
> >>>
> >>> Could not commit changes to layer Sito_Puntuale
> >>>
> >>> Errors: ERROR: 1 feature(s) not added.
> >>>
> >>> Provider errors:
> >>>
> >>> PostGIS error while adding features: ERRORE: la query "SELECT codcom
> FROM
> >>> public.am_com AS c,indagini."Sito_Puntuale" AS s WHERE (ST_Within( $1
> >>> ,c.geom))" ha restituito più di una riga
> >>>
> >>> CONTEXT: funzione PL/pgSQL "cal_idn" riga 5 a assegnazione
> >>>
> >>>
> >>> Il tutto funziona solo con il 1° punto inserito in una tabella vuota.
> Mi
> >>> sembra di aver capito che il problema risieda nel fatto che la funzione
> >>> ST_Within considera tutte le geometriepresenti nella tabella
> >>> “Sito_puntuale”
> >>> e non solo la NEW….
> >>>
> >>> Qualche buon anima mi saprebbe aiutare?
> >>>
> >>> Grazie in anticipo
> >>>
> >>>
> >>> Alessandro Ciali
> >>>
> >>> Da: Luca Lanteri
> >>> Data invio: lunedì 13 luglio 2015 09:21
> >>> A: Alessandro Ciali
> >>> Cc: GFOSS.it
> >>>
> >>> CIao Alessandro,
> >>> grazie mille per la disponibilità.
> >>>
> >>> Non ti preoccupare, tutto quello che vedi è stato fatto da autodidatti
> >>> con
> >>> conoscenze minime di programmazione, e proprio per questo che è ancora
> >>> più
> >>> importante unire forze e le competenze.
> >>> In Piemonte diversi professionisti hanno iniziato ad utilizzare questi
> >>> strumenti (mi pare di capire con soddisfazione) per realizzare i propri
> >>> approfondimenti di microzonazione sismica con QGIS e stanno svolgendo
> un
> >>> bel
> >>> lavoro di testing.
> >>>
> >>> A disposizione per qualsiasi chiarimento.
> >>> a presto
> >>> Luca
> >>>
> >>>
> >>> Il giorno 11 luglio 2015 17:46, Alessandro Ciali
> >>> <alessandro.ciali a gmail.com> ha scritto:
> >>>>
> >>>>
> >>>>
> >>>> Sarei ben lieto di partecipare al miglioramento, a che non sono un
> genio
> >>>> della programmazione .a piuttosto un autodidatta coatto. Intanto
> >>>> scarichero'
> >>>> il tutto dal sito dell'ARPA per vedere se e come il mio lavoro possa
> >>>> integrare ciò che è stato fatto. Lavorando in parte nel campo della
> >>>> geologia
> >>>> per la pianificazione territoriale, ma lavorando prev. In toscana, ho
> >>>> sviluppato librerie di simboli che si attengono alle specifiche di
> >>>> questa
> >>>> regione; non mi sembra di aver trovato sul sito della RT librerie
> >>>> specifiche
> >>>> per QGIS, io le condividerei volentieri; anzi visto che alcuni membri
> >>>> di
> >>>> RT
> >>>> partecipa a questa lista, potrebbero, se sono interessati, a darmi
> >>>> informazioni in merito. Per adesso grazie per le dritte, spero di
> poter
> >>>> contribuire. Saluti a tutti
> >>>>
> >>>> Inviato da Samsung Mobile.
> >>>>
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Gfoss a 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.
> >>> 750 iscritti al 18.3.2015
> >>
> >>
> >>
> >> --
> >> -----------------
> >> Andrea Peri
> >> . . . . . . . . .
> >> qwerty àèìòù
> >> -----------------
> >
> >
> >
> > --
> > -----------------
> > Andrea Peri
> > . . . . . . . . .
> > qwerty àèìòù
> > -----------------
>
>
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -----------------
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20150720/45500af2/attachment.html>
Maggiori informazioni sulla lista
Gfoss