[Gfoss] Quale formato?

a.furieri a lqt.it a.furieri a lqt.it
Mar 18 Nov 2014 10:36:23 CET


On Tue, 18 Nov 2014 09:25:45 +0100, Luca Lanteri wrote:
>> 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 ?
>  

certo che puoi eliminare tutti i CRS che non utilizzi e che non
prevedi di utilizzare mai.
in fondo l'effetto e' sempre il medesimo: sia che tu applichi una
"inizializzazione leggera" tanto che tu faccia la classica
"inizializzazione completa" e poi elimini tutti hgli SRID che
non usi caschi sempre nel solito posto.
magari dopo avere eliminato gli SRIDridondanti ricordati sempre
di fare VACUUM per compattare fisicamente il DB-file.

le conseguenze di eliminare uno o piu' CRS sono queste due qua:
a) per potere creare una nuova geometria occorre che lo SRID che
    dichiari sia presente in "spatial_ref_sys"; se manca ti
    dara' un errore fatale.
b) idem per la ST_Transform(): se non trova la definizione dello
    SRID anche questa ti da' errore.

insomma, se tu sei ben sicuro che nei tuoi db-file ci andranno
sempre e solo dati piemontesi, non ti serve poi a molto tenerti
nel db tutti gli SRID relativi agli USA o all'oceano pacifico ;-)


>  .) non consente la rinomina o la cancell
>
>> ' 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 ?
>

certamente si: e pure se hai gia' definito qualche VIEW potrebbe
saltare perche' i nomi non combaciano piu'.
idem dicasi se hai definito qualche Trigger customizzato.

funziona sicuramente bene nel caso di tavole semplici che non siano
coinvolte in troppe ulteriori ramificazioni; nei casi piu' complessi
non funziona.

ciao Sandro


Maggiori informazioni sulla lista Gfoss