[Gfoss] PostgreSQL/PostGIS - rule Insert su vista con join

Ven 25 Set 2015 17:04:24 CEST

>
>  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 <pigrecoinfinito a 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 <
> beppenapo a 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 a 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.marucci a 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 <
>>>> pigrecoinfinito a gmail.com> ha scritto:
>>>>
>>>>> FANTASTICO!!!!
>>>>>
>>>>> grazie al consiglio di Francesco ho ottenuto il risultato auspicato,
>>>>> semplicemente aggiungendo:
>>>>>
>>>>> Default value = lastval().
>>>>>
>>>>> grazie!!!
>>>>>
>>>>> saluti
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> *Salvatore Fiandaca*
>>> *mobile*.:+39 327.493.8955
>>> *m*: *pigrecoinfinito a gmail.com <pigrecoinfinito a gmail.com>*
>>> 43°51'0.54"N  10°34'27.62"E - EPSG:4326
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>>
>> --
>> *Giuseppe Naponiello*
>>
>> *A**rc-**T**eam srl*
>> piazza Navarrino, 13 - 38023Cles (TN)
>> C.F. e P. IVA IT-01941600221
>> cell. +393476846599
>> mail: beppenapo a arc-team.com
>> pec: arc-team a pec.it
>> www.arc-team.com
>> http://arc-team-open-research.blogspot.it/
>>
>
>
>
> --
> *Salvatore Fiandaca*
> *mobile*.:+39 327.493.8955
> *m*: *pigrecoinfinito a gmail.com <pigrecoinfinito a 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: beppenapo a arc-team.com
pec: arc-team a pec.it
www.arc-team.com
http://arc-team-open-research.blogspot.it/
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20150925/e44cf95f/attachment-0001.html>