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:
- le due tabelle sono nate in tempi diversi;
- 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;
- nella tabella B, quella con geometria in realtà contiene anche altri dati;
- 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 <beppenapo@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 <pigrecoinfinito@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?
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-Team srl
piazza Navarrino, 13 - 38023Cles (TN)
C.F. e P. IVA IT-01941600221
cell. +393476846599
mail: beppenapo@arc-team.com
pec: arc-team@pec.it
www.arc-team.com
http://arc-team-open-research.blogspot.it/
Il giorno 25 settembre 2015 14:01, francesco marucci <francesco.marucci@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…
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: pigrecoinfinito@gmail.com
43°51’0.54"N 10°34’27.62"E - EPSG:4326
Il giorno 25 settembre 2015 13:41, Totò Fiandaca <pigrecoinfinito@gmail.com> ha scritto:
FANTASTICO!!!
grazie al consiglio di Francesco ho ottenuto il risultato auspicato, semplicemente aggiungendo:
Default value = lastval().
grazie!!!
saluti
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51’0.54"N 10°34’27.62"E - EPSG:4326
