> > 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 <pigrecoinfin...@gmail.com> ha scritto: > 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 > > > -- *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/
_______________________________________________ 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
