[Gfoss] Quale formato?

a.furieri a lqt.it a.furieri a lqt.it
Mar 11 Nov 2014 00:11:49 CET


On Mon, 10 Nov 2014 23:18:05 +0100, Andrea Peri wrote:
> =====
> Lista difetti dello SpatiaLite
>

giusto per doverosa informazione tecnica peramente oggettiva :-)

> .) overhead dimensionale non trascurabile (4mb) che limita il suo
> impiego quando i dati sono pochi.
>

mica e' vero che l'ovehead deve essere necessariamente "pesante"

test 1)
-------
sqlite3 pippo1.sqlite
SELECT load_extension('mod_spatialite');
SELECT InitSpatialMetadata(1);
.quit

questa e' l'inizializzazione "by default" e carica circa 4,800 SRS
dentro a "spatial_ref_sys" (cioe' tutto il dataset EPSG integrale).
size: 4.75 MB


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


test 3)
-------
sqlite3 pippo3.sqlite
SELECT load_extension('mod_spatialite');
SELECT InitSpatialMetadata(1, 'NONE');
SELECT InsertEpsgSrid(3003);
.quit

infine questa e' l'inizializzazione "ultra-light"; "spatial_ref_sys"
viene creato ma resta assolutamente vuoto !!!
a seguire, tramite una o piu' chiamate a InsertEpsgSrid() e' poi 
possibile
inserire selettivamente solo quegli SRID che servono a quello specifico
DB (nell'esempio: solomente Roma 1940 Gauss Boaga Ovest)
size: 120 KB


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.


>
> .) 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

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).

ciao Sandro


Maggiori informazioni sulla lista Gfoss