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 <beppen...@gmail.com> ha scritto: > 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 < > pigrecoinfin...@gmail.com> ha scritto: > >> 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 < >> francesco.maru...@gmail.com> ha scritto: >> >>> 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 < >>> pigrecoinfin...@gmail.com> ha scritto: >>> >>>> FANTASTICO!!!! >>>> >>>> grazie al consiglio di Francesco ho ottenuto il risultato auspicato, >>>> semplicemente aggiungendo: >>>> >>>> Default value = lastval(). >>>> >>>> grazie!!! >>>> >>>> saluti >>>> >>>> >>> >>> _______________________________________________ >>> 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. >>> 750 iscritti al 18.3.2015 >>> >> >> >> >> -- >> *Salvatore Fiandaca* >> *mobile*.:+39 327.493.8955 >> *m*: *pigrecoinfin...@gmail.com <pigrecoinfin...@gmail.com>* >> 43°51'0.54"N 10°34'27.62"E - EPSG:4326 >> >> >> >> _______________________________________________ >> 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. >> 750 iscritti al 18.3.2015 >> > > > > -- > *Giuseppe Naponiello* > > *A**rc-**T**eam srl* > piazza Navarrino, 13 - 38023Cles (TN) > C.F. e P. IVA IT-01941600221 > cell. +393476846599 > mail: beppen...@arc-team.com > pec: arc-t...@pec.it > www.arc-team.com > http://arc-team-open-research.blogspot.it/ > -- *Salvatore Fiandaca* *mobile*.:+39 327.493.8955 *m*: *pigrecoinfin...@gmail.com <pigrecoinfin...@gmail.com>* 43°51'0.54"N 10°34'27.62"E - EPSG:4326
_______________________________________________ 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. 750 iscritti al 18.3.2015
