Buongiorno a tutti; ho realizzato una vista con join tra due tabelle, la prima contiene solo dati alfanumerici la seconda solo la geometria. Utilizzo questa vista anche per eventuali modifiche (rule update) e inserimenti (rule insert); domande: 1. come fare una unica rule (insert o update) se le tabelle sono due? 2. come fare ad aggiornare o inserire il campo unione tra le due tabelle in join? cioè il campo con cui faccio il join è pk nella prima tabella e fk nella seconda; come fare per aggiornarle in automatico attraverso le rule? spero di essermi spiegato bene (sono un autodidatta di pg). grazie!! _______________________________________________ [hidden email] 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 |
Ciao Totò,
se ho capito bene la tua domanda, il tuo problema/quesito è simile a questo ?? http://stackoverflow.com/questions/10471757/insert-rows-into-multiple-tables-in-a-single-query-selecting-from-an-involved-t Saluti Nino |
nel link che mi hai postato c'è troppa confusione e non riesco a seguire bene. cerco di fare un esempio più semplice: ho creato una vista 'V' partendo da due tabelle 'A' e 'B', tabelle in relazione (1:1) tramite il campo 'ID'; ho creato tre rule nella vista: una per inserimento dati per la tabella A, una per inserimento dati per la tabella B ed infine una rule per aggiornamento dei dati della tabella A; queste rules mi permettono, aggiungendo la vista in qgis, di modificare ed inserire righe nuove; il mio problema è il seguente: da qgis, in modalità modifica, inserisco un nuovo record (nuova geometria) e dopo aver digitato la geometria, giustamente, compare la finestra per inserire i dati; in questa finestra compaiono solo i campi delle due tabelle (vista) ad eccezione del campo ID unione (il join) della seconda tabella (cosa che accade sempre in qgis; l'ID della tabella A è serial not null (quindi autoincremetale) ma l'ID della tabella 'B' (fk) è integer e non compare nella finestra per l'inserimento dati (cosa normale); chiedevo come fare (tramite rule o trigger) a impostare, durante l'inserimento di un record, il valore ID della tabella B uguale al valore ID della tabella A; altrimenti la vista non mi farebbe più vedere il legame tra le due tabelle. troppe parole per un problema semplice, ma che ancora non riesco a risolvere (carenze di nozioni plpgsql) ma ho la testa dura!!! so che è possibile farlo... devo trovare il modo. ciao 2015-09-24 17:07 GMT+02:00 nformica <[hidden email]>: Ciao Totò, _______________________________________________ [hidden email] 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 |
ciao, saluti, Il 24/set/2015 08:01 PM, "Totò Fiandaca" <[hidden email]> ha scritto:
_______________________________________________ [hidden email] 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 |
si, potrei farlo vedere il campo ID della tabella B, ma il problema non cambia; i due ID, dopo l'inserimento, devono essere uguali!!! potrei farlo manualmente, ma non sarebbe elegante!!! Il giorno 24 settembre 2015 20:13, francesco marucci <[hidden email]> ha scritto:
_______________________________________________ [hidden email] 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 |
Ciao Totò,
allora, la tua esigenza, per esprimersi tecnicamente, è quella di garantire l' "integrità REFERENZIALE" di due tabelle correlate, quando fai operazioni di INSERT o UPDATE, con un' unica rule. (tu stesso puoi cercare in rete e troverai tante info). Ti rispondo che, per quanto ne sappia io (... e vale in generale per qualunque DB relazionale) con un' unica rule non ci si riesce !! Ma magari un amico su questa lista, più esperto di DB, mi può contraddire e spiegarci come fare !? Cari saluti Nino |
In reply to this post by pigreco
scusa, ma hai provato a con la sequenza anche sul campo ID della tabella B? Il giorno 24 settembre 2015 20:34, Totò Fiandaca <[hidden email]> ha scritto:
_______________________________________________ [hidden email] 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 |
Buongiorno Nino e Francesco, vi rispondo ad entrambi @Nino: conosco i vincoli di integrità referenziale, ma come vuole la teoria se esiste una pk (lato tabella madre) non è detto che esista una fk (lato tabella figlia) ma è necessaria al contrario. Nel mio caso vorrei automatizzare il processo nel senso che appena creo una nuova pk si dovrebbe creare (con valore uguale) la fk nell'altra tabella. come fare? per quanto riguarda il numero di rule: non saprei, io ho creato tre rules. @Francesco: l'ID della tabella B è di tipo integer, mi risulta impossibile cambiare il datatype in serial!!! grazie ad entrambi. saluti Il giorno 25 settembre 2015 10:43, francesco marucci <[hidden email]> ha scritto:
_______________________________________________ [hidden email] 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 |
non è necessario cambiarlo in serial, guardati pero' qui cosa devi mettere al posto di nextval per sincronizzare i due valori:puoi dargli il DEFAULT, qualcosa del genere: ALTER TABLE [tabella B] ALTER COLUMN id SET DEFAULT nextval('sequenza del gid della tabella A'); http://www.postgresql.org/docs/9.4/static/functions-sequence.html Il giorno 25 settembre 2015 11:36, Totò Fiandaca <[hidden email]> ha scritto:
_______________________________________________ [hidden email] 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 |
In reply to this post by pigreco
... come ti dicevo nella risposta precedente, che io sappia: 'n se po fa !! Ciao ! Nino |
FANTASTICO!!!! grazie al consiglio di Francesco ho ottenuto il risultato auspicato, semplicemente aggiungendo: Default value = lastval(). grazie!!! saluti Il giorno 25 settembre 2015 12:00, nformica <[hidden email]> ha scritto: pigreco wrote _______________________________________________ [hidden email] 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 |
quindi ci confermi che ad un insert sulla vista viene effettuato il PRIMO insert nella tabella A (facendo scattare la sequenza) e il SECONDO nella tabella B (sfruttando l'ultimo valore della sequenza), sempre in questo ordine? altrimenti il tuo giochino non funzionerebbe mica... Il giorno 25 settembre 2015 13:41, Totò Fiandaca <[hidden email]> ha scritto:
_______________________________________________ [hidden email] 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 |
aggiungo qualche altro dettaglio, come ho già scritto le due tabelle sono in relazione 1:1, la tabella A (ID serial not null (pk), ....) contiene solo dati alfanumerici e la tabella B ha (per il momento) solo tre campi (gid serial not null (pk), geom geometry, ID integer (fk)); caricando la vista in QGIS, il primo inserimento è sulla tabella B (inserisco la geometria) quindi scatta la sequenza della gid (che è pk autoincremetale tabella B), lastval() prende (credo) questo valore, valore che ha la stessa sequenza di ID tabella A (sono in relazione 1:1). ho fatto, velocemente, altre prove con le diverse funzioni sequenza (es. currval) ma non ho ottenuto l'esito voluto. secondo te potrei migliorare qualcosa? Il giorno 25 settembre 2015 14:01, francesco marucci <[hidden email]> ha scritto:
_______________________________________________ [hidden email] 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 |
Ciao, giusto una curiosità, se la tabella B è solo "geometrica" e la relazione con la tab A è 1:1, immagino che nel tuo schema ad ogni record di A può corrispondere solo 1 record di B, quindi 1 sola geometria... c'è un motivo particolare per cui hai deciso di dividere le 2 tabelle e non inserire direttamente un campo geometrico in A? Altra osservazione banale, se c'è una logica sottesa al tipo di struttura usata per il db, per la quale hai bisogno di 2 tabelle, se la fk di B e la pk di A devono essere "sincronizzate" perché non eliminare il campo B.gid e utilizzare B.id sia come pk (serial oppure integer + sequenza di default) che come fk? E ancora, teniamo sempre buone le 2 tabelle, se non ho capito male lavori prevalentemente sulla tab B, quella "geometrica", da qgis...giusto? In questo caso non conviene "invertire" le fk? Cioè inserire una fk in A verso B, in questo modo dovrebbe essere più semplice gestire l'integrità referenziale: se cancelli una geometria, a cascata cancelli anche il record alfanumerico senza bisogno di procedure più complesse, evitando al tempo stesso di avere orfani in A. E infine, che versione di postgres usi? Hai provato le viste materializzate? -beppe- Il giorno 25 settembre 2015 14:47, Totò Fiandaca <[hidden email]> ha scritto:
Giuseppe Naponiello Arc-Team srl piazza Navarrino, 13 - 38023Cles (TN) C.F. e P. IVA IT-01941600221 cell. +393476846599 mail: [hidden email] pec: [hidden email] www.arc-team.com http://arc-team-open-research.blogspot.it/ _______________________________________________ [hidden email] 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 |
Ciao Giuseppe ti rispondo: domanda: giusto una curiosità, se la tabella B è solo "geometrica" e la relazione con la tab A è 1:1, immagino che nel tuo schema ad ogni record di A può corrispondere solo 1 record di B, quindi 1 sola geometria... c'è un motivo particolare per cui hai deciso di dividere le 2 tabelle e non inserire direttamente un campo geometrico in A? risposta: i motivi sono vari: 1. le due tabelle sono nate in tempi diversi; 2. per motivi di chiarezza ho suddiviso il mio DB PostgreSQL 9.3.9 in tre schemi (tabelle solo dati, tabelle con geometry, strati di sfondo) come hai capito lavoro spesso con QGIS; 3. nella tabella B, quella con geometria in realtà contiene anche altri dati; 4. mi piace percorrere strade nuove per fare esperienza, come in questo caso; domanda: Altra osservazione banale, se c'è una logica sottesa al tipo di struttura usata per il db, per la quale hai bisogno di 2 tabelle, se la fk di B e la pk di A devono essere "sincronizzate" perché non eliminare il campo B.gid e utilizzare B.id sia come pk (serial oppure integer + sequenza di default) che come fk? risposta: ottima osservazione, ma a questo punto se dovessi fare delle modifiche preferirei unire le due tabelle; domanda: E ancora, teniamo sempre buone le 2 tabelle, se non ho capito male lavori prevalentemente sulla tab B, quella "geometrica", da qgis...giusto? In questo caso non conviene "invertire" le fk? Cioè inserire una fk in A verso B, in questo modo dovrebbe essere più semplice gestire l'integrità referenziale: se cancelli una geometria, a cascata cancelli anche il record alfanumerico senza bisogno di procedure più complesse, evitando al tempo stesso di avere orfani in A. risposta: ottima osservazione, ma a questo punto se dovessi fare delle modifiche preferirei unire le due tabelle; domanda: E infine, che versione di postgres usi? Hai provato le viste materializzate? risposta: PostgreSQL 9.3.9/ PostGIS 2.1.7; è la prima volta che sento parlare delle viste materializzate, da una rapida richerca ho visto che sono molto interessanti. ciao e grazie PS: utilizzo da poco PostgreSQL/PostGIS e da autodidatta. Il giorno 25 settembre 2015 15:26, Giuseppe Naponiello <[hidden email]> ha scritto:
_______________________________________________ [hidden email] 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 |
mi piace percorrere strade nuove per fare esperienza, come in questo caso; Ottimo, anch'io penso che "sperimentare" sia il modo migliore per imparare ;) PS: utilizzo da poco PostgreSQL/PostGIS e da autodidatta. Attenzione, postgres e postgis possono dare dipendenza, se ti prende bene ed entri nel tunnel non ne esci più!!! Scherzi a parte, le potenzialità sono infinite: gestione dei raster, gestione di formati moooolto interessanti come json o xml, gestione della terza dimensione per le geometrie, foreign data wrapper...insomma, lavorare con postgres, almeno per me, è un piacere! Ribadisco, le mie erano semplici curiosità: capire come lavorano altre persone può aiutare a migliorare il proprio lavoro. In bocca al lupo e buon lavoro ;) -beppe- Il giorno 25 settembre 2015 16:05, Totò Fiandaca <[hidden email]> ha scritto:
Giuseppe Naponiello Arc-Team srl piazza Navarrino, 13 - 38023Cles (TN) C.F. e P. IVA IT-01941600221 cell. +393476846599 mail: [hidden email] pec: [hidden email] www.arc-team.com http://arc-team-open-research.blogspot.it/ _______________________________________________ [hidden email] 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 |
In reply to this post by Giuseppe Naponiello
Questa delle viste materializzate :
è una cosa che non conoscevo neanche io ! Per cui grazie della dritta. ![]() Ciao ! Nino |
ti chiedo una cortesia, come faccio ad installare il plugin postgis per la visualizzazione dei vettori? Ho scaricato uno zip da qui [0], ed ho seguito le istruzioni presenti sul sito. Sul sito che ti ho linkato ad un certo punto dice di aggiungere la definizione del plugin nel file /usr/share/pgadmin3/plugins.ini, in debian 8 il percorso corretto è /usr/share/pgadmin3/plugins.d/plugins.ini. Se tutto va a buon fine in pgadmin accedi al viewer dal menù plugin ... in teoria dovresti potervi accedere anche dall'icona con i pezzi del puzzle ma a me da sempre un errore legato alle wxWidgets. ;) Giuseppe Naponiello Arc-Team srl piazza Navarrino, 13 - 38023Cles (TN) C.F. e P. IVA IT-01941600221 cell. +393476846599 mail: [hidden email] pec: [hidden email] www.arc-team.com http://arc-team-open-research.blogspot.it/ _______________________________________________ [hidden email] 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 |
grazie Giuseppe, ricordo di aver seguito questa guida tempo fa con esito negativo, ma riproverò Il giorno 25 settembre 2015 23:34, Giuseppe Naponiello <[hidden email]> ha scritto:
_______________________________________________ [hidden email] 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 |
Free forum by Nabble | Edit this page |