Ciao Andrea, il fatto è proprio questo, vorrei appunto evitare di trovarmi a cose fatte con un problema da gestire. Credo che ora che tutto è in fase di startup ancora protrei ovviare a problemi che prevedo ci saranno; per quelli che non prevedo amen! :D
Il giorno 13 dicembre 2017 16:35, Andrea Peri <aperi2...@gmail.com> ha scritto: > Infatti queste cose non sono facili per niente. > Però il tuo approccio è sano. > Ovvero hai d lle specifiche e stai valutando come fare per ottenere il > sistema nell'ansia completezza. > Ora che conosci meglio i limiti di un determinato stack tecnologico puoi > decidere se introdurre nel tuo sistema infrastrutturale dei cambiamenti che > superino i limiti identificati oppure cambi qualcosa nellonstack. > > Sempre meglio che partire mettendo in piedi un sistema che abbozza il > funzionamento rimandando certi studi a quando non è più differisce e solo a > quel momento scoprire i limiti e non sapere come fare a risolverli. > > > Il 13 Dic 2017 3:19 PM, "Massimiliano Moraca" < > massimilianomor...@gmail.com> ha scritto: > >> La facevo facile quindi io Sandro.. :| >> >> hint: ma perche' vuoi usare proprio una Spatial View ? >> > nel tuo caso, se ho capito bene il problema, sarebbe molto >> > piu' opportuno materializzare ancora un'altra tavola, p.es.: >> >> >> Voglio creare una view in virtù del fatto che si autoaggiorna...in pratica >> ogni tanto capita che mi venga chiesto di spostare un villaggio da una >> categoria all'altra e rifare la tabella ogni volta è scocciante. Mi spiego >> meglio. Il file in questione è solo un estratto depurato di tutta una >> serie >> di informazioni(per motivi di privacy relativa al progetto) che rientrano >> in una decina di colonne. Ad esempio: >> >> Nome|Colore|tipo|area >> A|rosso|tipo1|10 >> B|verde|tipo2|100 >> C|blu|tipo1|3 >> D|rosso|tipo1|450 >> E|blu|tipo3|753 >> >> Se per qualche motivo B deve diventare tipo3 ed io ho un raggruppamento >> per >> tipo con una sommatoria delle aree per tipo, con la view mi basta cambiare >> il dato nella tabella sorgente per avere attivo l'automatismo; altrimenti >> dovrei creare una nuova tabella ogni volta. >> >> Il giorno 13 dicembre 2017 14:56, <a.furi...@lqt.it> ha scritto: >> >> > On Wed, 13 Dec 2017 13:56:20 +0100, Massimiliano Moraca wrote: >> > >> >> Come ho detto a Marco ogc_fid è chiave primaria. Avevo notato >> >> un po' di tempo fa che nel creare le VIEW SpatiaLite ti chiede >> >> comunque un id dalla tabella sorgente, id assegnato poi random. >> >> >> >> >> > Massimiliano, >> > >> > stai ben attento perche' qua rischi di combinare un bell'arrosto. >> > >> > 1. "nel creare le VIEW SpatiaLite ti chiede comunque un id dalla >> > tabella sorgente" >> > >> > esatto, e' proprio cosi': per la precisione ti chiede di >> > specificare quale sia il nome della colonna-VIEW che riporta >> > il ROWID che identifica la riga della tavola-input che >> > fornisce la geometria presente nella View. >> > Corollario: una Spatial View di SpatiaLite non puo' mai >> > fornire una geometria che sia il risultato di una funzione >> > o il frutto di una aggregazione. >> > _DEVE_ necessariamente essere una geometria presa tal >> > quale da una delle tavole di input della View, senza che >> > intervenga nessuna manipolazione di sorta. >> > e la colonna "rowid" presente nella Spatial View deve >> > consentire di tenere coerentemente in synchro le righe >> > della tavola-madre con il suo eventuale Spatial Index. >> > >> > >> > 2. "id assegnato poi random" >> > >> > assolutamene _NO_ !!!! >> > non puo' essere random, _DEVE_ identificare esattamente >> > la riga della tavola che fornisce la geometria (ergo, o >> > si tratta di una PK oppure in forma piu' geerica di un >> > ROWID). >> > e c'e' un motivo assolutamente stringente per imporre >> > questo vincolo: altrimenti lo Spatial Index (che e' sempre >> > basato sulla tavola primaria e non sulla View) impazzisce, >> > e fornira' risultati padellati di pura fantasia con >> > risultati folli e potenzialmete devastanti. >> > in buona sostanza, se nella colonna ROWID della Spatial >> > View fai in modo che ci finiscano "valori random" stai >> > facendo tutto il possibile per massacrare la logica di >> > funzionamento dello Spatial Index. >> > per inciso, ti ricordo che su SQLite/SpatiaLite lo >> > Spatial Index R*TRee non e' affatto un "indice", ma e' >> > semplicemente un'ulteriore tavola, anzi per l'esattezza >> > e' una VirtualTable. >> > funziona, e funziona pure in modo molto efficiente, ma >> > esige lo scrupoloso rispetto di tutta una serie di vincoli >> > basati sullo scrupoloso rispetto dei JOIN relazionale >> > basati sul ROWID, altrimenti salta tutto per aria. >> > >> > hint: ma perche' vuoi usare proprio una Spatial View ? >> > nel tuo caso, se ho capito bene il problema, sarebbe molto >> > piu' opportuno materializzare ancora un'altra tavola, p.es.: >> > >> > CREATE TABLE dipart2 AS >> > SELECT cd_diparti, dipartimen, ST_Union(geom) AS geometry >> > FROM dipartimenti >> > GROUP BY cd_diparti; >> > SELECT RecoverGeometryColumn('dipart2', 'geometry', ......); >> > SELECT CreateSpatialIndex('dipart2', 'geometry'); >> > >> > ciao Sandro >> > >> > >> _______________________________________________ >> 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. >> 801 iscritti al 19/07/2017 > > _______________________________________________ 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. 801 iscritti al 19/07/2017