Grazie mille delucidazioni Alessandro.
Buona giornata
Il giorno 15 novembre 2017 10:13, <a.furi...@lqt.it> ha scritto:
> On Wed, 15 Nov 2017 09:36:53 +0100, Massimiliano Moraca wrote:
>
>> Nel caso specifico del db ISTAT precedentemente avevo fatto un LEFT
>> JOIN tra le geometrie ed il csv dei dati statistici, dovrei quindi
>> riportare oltre alle colonne che hai indicato anche il resto:p1, p2,
>> ...st9 etc. E' lunghetto da scrivere ma se mi dici che non conviene
>> usare SELECT* allora la strada è una. Toglimi una curiosità,
>> premetto che ho conoscenze basilari di SQL e ne faccio un uso
>> discontinuo, il non usare SELECT* è dato da una limitazione di
>> SpatiaLite (essendo una LITE) o vale per ogni DMBS?
>>
>>
> ciao Massimiliano,
>
> direi proprio che e' una buona abitudine che vale per qualsiasi
> DBMS, per un motivo abbastanza semplice.
> quando tu scrivi "SELECT *" stai autorizzando il DBMS ad
> assegnare i nomi-colonna come meglio preferisce, ed a volte
> potrebbero nascere situazioni difficili da gestire.
>
> giusto qualche esempio a caso:
> - nel caso in cui la colonna 'pippo' sia presente sia nella
> tavola 'a' che nella tavola 'b' potresti poi scoprire che
> la tua View contiene una colonna di nome 'a.pippo' ed
> un'altra di nome 'b.pippo'; questi sono nomi SQL rognosi,
> che poi ti costringeranno ad usare il quoting tra doppie
> virgolette per mascherare il nome illegale.
> decisamente meglio evitare di finire in situazioni di questo
> tipo.
> - versioni diverse del DBMS potrebbero usare criteri diversi
> per assegnare automaticamente i nomi-colonna alle View; e
> quindi tu potresti anche scoprire che la tua View funziona
> bene solo su alcune macchine ma non su altre.
>
> insomma, e' essenzialmente un problema di autorita' e di controllo;
> gli utenti occasionali trovano comodo affidarsi alle decisioni
> automatiche del DBMS perche' (apparentemente) costa poca fatica.
> invece gli utenti professionali specificano sempre tutto in modo
> esplicito evitando accuratamente di affidarsi ai default
> automatici perche' non gradiscono avere sorprese inattese.
>
>
> Toglimi una curiosità. ST_DISTANCE se usato in solitaria mi permette
>> di creare un buffer visibile in QGIS
>>
>>
> no; e' semplicemente un calcolo che ritorna un valore Double Precision,
> non una geometria.
>
>
> potrei pure cavarmela con il virtual layer di QGIS ma se ne può
>> creare solo uno ed a me ne servono 4: 250m, 500m, 750m, 1000.
>>
>>
> guarda che con SpatiaLite puoi risolvere questo problema in modo
> molto semplice. basta solo che tu aggiunga altre quattro colonne
> geometriche alla tua tavola "input" e QGIS le vedra' poi come
> se fossero layers distinti. prova qualcosa del genere:
>
> SELECT AddGeometryColumn('input', 'buf250', 32632, 'POLYGON', 'XY');
> SELECT AddGeometryColumn('input', 'buf500', 32632, 'POLYGON', 'XY');
> SELECT AddGeometryColumn('input', 'buf750', 32632, 'POLYGON', 'XY');
> SELECT AddGeometryColumn('input', 'buf1000', 32632, 'POLYGON', 'XY');
>
> UPDATE input SET buf250 = ST_Buffer(geom, 250.0);
> UPDATE input SET buf500 = ST_Buffer(geom, 500.0);
> UPDATE input SET buf750 = ST_Buffer(geom, 750.0);
> UPDATE input SET buf1000 = ST_Buffer(geom, 1000.0);
>
> 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
