[Gfoss] Quale formato?

[Luca Lanteri]

Il giorno 11 novembre 2014 00:11, <a.furieri a lqt.it> ha scritto:

> On Mon, 10 Nov 2014 23:18:05 +0100, Andrea Peri wrote:
>
>> =====
>> Lista difetti dello SpatiaLite
>>
>>
> [...]
>
>
> test 2)
> -------
> sqlite3 pippo2.sqlite
> SELECT load_extension('mod_spatialite');
> SELECT InitSpatialMetadata(1, 'WGS84');
> .quit
>
> questa invece e' l'inizializzazione "leggera"; dentro a "spatial_ref_sys"
> ci finiscono solo 130 righe, cioe' tutta la famiglia WGS84: 4326 + tutti
> i fusi dal 32601 fino al 32766.
> size: 256 KB
>
>
> Bella questa, no la conoscevo !
Io in genere creo i db da spatialite-gui. Posso creare un DB con tutti i SR
e poi eliminare quelli che non mi servono o in questo modo si crea qualche
problema ?


>
>
>
> SpatiaLite mette a disposizione tutte le funzioni SQL che servono
> per modulare a piacere l'inizializzazione nel modo piu' flessbilie
> e senza nessun vincolo imposto.
> il fatto che ancora ad oggi nessun client / app  supporti quanto e'
> gia' disponibile almeno da due o tre anni a questa parte non e'
> certo un difetto imputabile al DBMS in quanto tale.


Assolutamente no. Come gia dicevo tempo fa un campo su cui c'è molto da
fare è proprio migliorare l'integrazione di SL con  i client GIS, visto che
poi è la modalità di accesso di buona parte degli utenti medi.
Con una buona integrazione SL potrebbe veramente diventare lo shapefile del
futuro, visto che le potenzialità di un DBMS sono infinitamente più ampie.



>> .) non consente la rinomina o la cancellazione di una colonna
>>
>> dif: 1  nodif: 1
>>
>>
> verissimo: e' un limite strutturale intrinseco dell'architettura di
> SQLite. e non e' neppure ipotizzabile che venga modificato in un
> futuro piu' o meno vicino perche' implicherebbe rivoluzionare
> radicamente tutta la struttura fisica di basso livello del DB-file.
>
> detto questo: anche moltissimi altri DBMS non sono minimamente
> capaci di modificare i nomi/tipi/vincoli delle colonne una volta
> che siano state create.
> ma aggirano elegantemente il problema "simulando" a livello puramente
> formale una ALTER TABLE  che in effetti compie (sotto al cofano, in
> modo silenzioso ed invisibile) la seguente catena di operazioni:
>
> 1) attivare una transazione - BEGIN
> 2) modificare il nome della tavola di partenza
> 3) creare una nuova tavola con il vecchio nome ma sopprimendo
>    (o modificando) le definizioni delle singole colonne cosi'
>    come richiesto dall'utente.
> 4) copiare i dati dalla tavola vecchia alla nuova
> 5) DROP della vecchia tavola
> 6) consolidare la transazione - COMMIT
>
>
Se ci sono relazioni con altre tavole ci possono essere problemi in questo
workaround ?


> SQLite non supporta nulla di simile: ma nulla vieta che un client
> o una app si implementino autonomamente una funzionalita' di questo
> tipo. p.es. SpatiaLite-GUI la supporta pienamente fin da tempi
> assai remoti.
> nulla vieta (almeno in teoria) che anche ulteriori client "di buona
> volonta'" supportino questa funzionalita' in modo del tutto
> trasparente (cioe' senza che l'utente neppure se ne accorga).
>

+1


> ciao Sandro


Grazie delle solite ottime dritte.
a presto
Luca


> _______________________________________________
> 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.
> 666+40 iscritti al 5.6.2014
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20141118/7bbc81f7/attachment-0001.html>