[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