[Gfoss] Differenze tra Spatialite e Geopackage

Massimiliano Moraca massimilianomoraca a gmail.com
Gio 1 Mar 2018 23:31:14 CET


Alessandro grazie mille per la spiegazione esaustiva :)

Il giorno 1 marzo 2018 23:15, <a.furieri a lqt.it> ha scritto:

> On Thu, 1 Mar 2018 20:11:55 +0100, Massimiliano Moraca wrote:
>
>> Mi è ben chiara la distinzione tra DB e DBMS, non mi era chiaro il
>> fatto che un file .sqlite fosse esso stessi già un DBMS e che, ad
>> esempio, SpatiaLite GUI è una "semplice" gui perchè credevo
>> piuttosto che fosse il DBMS. Come accade quando si fa un dump da
>> PostGIS e lo si salva in .sql, questo file in se non può essere
>> gestito senza reinmetterlo in un DBMS.
>>
>> ------------------------ <snip> ---------------------------
>>
>> Il fraintendimento credo sia nato dal fatto che io quando parlo di DB
>> intendo un insieme di dati "fermi da qualche parte", come una serie di
>> raccoglitori con documenti tenuti in una cassettiera. Mentre per DBMS
>> intendo un software che processa quei dati e per client un software
>> che li visualizza. Almeno così l'avevo capita io.
>>
>>
> Massimiliano,
>
> quel che dici e' sostanzialmente corretto.
>
> un DBMS e' indiscutibilmente un software; che pero' richiede
> necessariamente un suo specifico spazio di storage fisico
> dove memorizzare i dati  e tutte le altre meta-strutture SQL
> (tavole, viste, vincoli, relazioni, indici, triggers etc) nel
> modo piu' opportuno ed efficiente.
>
> a questo punto pero' si apre un ampio ventaglio di possibili
> implementazioni, tutte ugualmente valide ma tutte radicalmente
> diverse l'una dall'altra.
>
> di norma lo storage legato ai DBMS e' qualcosa di abbastanza
> "misterioso ed oscuro", ed e' spesso strettamente legato ad
> una versione ben precisa del DBMS.
> per trasferire lo storage da una macchina all'altra, ma spesso
> anche solo per passare ad una versione piu' recente, e'
> indispensabile scaricare un dump che verra' successivamente
> ricaricato da zero.
>
> ------------
>
> SQLite invece adotta un'architettura radicalmente diversa;
> tanto per cominciare, non e' client-server, ma e' un
> "personal" DBMS, o se preferisci un "embedded" DBMS.
>
> questo significa che tutto il DBMS (ovvero lo SQL engine)
> consiste semplicemente in una libreria (libsqlite3) che
> deve necessariamente venire linkata all'interno di qualche
> applicazione per potere girare (spatialite_gui, QGIS o
> cosa altro ti pare).
>
> quindi quando tu dici che "SpatiaLite GUI è una 'semplice'
> gui perchè credevo piuttosto che fosse il DBMS" dici una
> cosa sia vera che falsa, dipende da come la prendi.
>
> per come la vedo io Spatialite GUI e' a tutti gli effetti
> una semplice GUI che si occupa solo della visualizzazione
> dei dati; tutto il "lavoro sporco" viene delegato al DBMS
> sottostante, che nello specifico e' rappresentato dalle
> due librerie libsqlite3 e libspatialite.
> il fatto che la comunicazione tra applicazione client e DBMS
> avvenga direttamente in RAM all'interno di un unico processo
> passando tramite API invece che attraverso una connessione
> di rete e' semplicemente un dettaglio tecnico, ma non altera
> la struttura dell'architettura di fondo.
>
> ma SQLite presenta ancora un'altra grossa specificita': lo
> storage consiste in un singolo file, il DB-file, che contiene
> al suo interno tutto quel che serve per memorizzare i dati
> e tutte le altre cianfrusaglie assortite richieste da SQL.
>
> a questo punto lo scenario diverge radicalmente da quelli
> piu' convenzionali di MySQL, PostgreSQL etc, in cui esiste
> un'unica istanza del DBMS che usa un singolo spazio di
> storage, piu' o meno variamente strutturato al suo interno.
>
> su SQLite puoi avere su di un'unica macchina centinaia e
> persino migliaia di DB-files completamente indipendenti
> l'uno  dall'altro; e li puoi piazzare a casaccio in qualsiasi
> cartella come meglio preferisci, le regole le stabilisce
> liberamente l'utente, non il DBMS.
> non solo: questi DB-files li puoi anche copiare "al volo"
> tra macchine diverse.
> e giusto per finire, su SQLite non dovrai mai fare un
> dump/reload, perche' qualsiasi versione successiva di SQLite
> (e di SpatiaLite) sara' sempre sicuramente in grado di leggere
> correttamente tutti i DB-files creati da una qualsiasi versione
> precedente.
> Naturalmente nulla assicura l'inverso; non e' sempre detto
> che una versione obsoleta di SQLite e/o SpatiaLite riesca a
> leggere correttamente un DB-file creato da una versione
> successiva.
>
> proprio come dici tu, un DB-file in fondo e' semplicemente
> "un  insieme di dati 'fermi da qualche parte', come una
> serie di raccoglitori con documenti tenuti in una
> cassettiera"
> ma per aprire correttamente tutti i cassetti e  recuperare
> tutti i documenti occorre pur sempre passare attraverso il
> DBMS, cioe' occorre chiamare le API della libsqlite3.
> non e' affatto importante se la libsqlite3 e' linkata dentro
> a QGIS o dentro a spatialite_gui o dentro ad un programma
> Python o Java; in ogni caso tutti gli accessi fisici allo
> storage passeranno comunque attraverso al solito SQL engine,
> quello della libsqlite3.
>
> tornando a bomba: e' proprio qua che si registra la
> principale differenza strutturale tra GeoPackage e
> SpatiaLite.
>
> - per riuscire ad aprire un GeoPackage basta la sola
>   libsqlite3 e niente altro.
>
> - invece per riuscire ad aprire un DB-file SpatiaLite
>   oltre alla libsqlite3 serve pure la libspatialite,
>   che a sua volta si tira dietro a catena tante altre
>   librerie: libgeos, libproj e libxml2 giusto per
>   citare solo le principali.
>
> ecco cosi' spiegato perche' GeoPackage non e' in grado
> di supportare uno Spatial Processing indipendente dalla
> applicazione host; perche' evidentemente si e' puntato
> a realizzare un data container quanto piu' semplice
> possibile che non implichi troppe dipendenze.
>
> gli obbiettivi di SpatiaLite sono esattamente opposti,
> visto che si prefigge lo scopo di offrire uno vero e
> proprio Spatial DBMS in grado di supportare uno Spatial
> Processing quanto piu' ricco e potente che sia possibile;
> anche a costo di introdurre qualche ulteriore complessita'
> strutturale.
>
> appunto come dicevo nell'altra mail; GeoPackage e
> SpatiaLite non sono affatto in concorrenza.
> GeoPackage e' una ragionevole alternativa ai vecchi
> Shapefiles, mentre SpatiaLite e' una ragionevole
> alternativa per PostGIS o per altri Spatial DBMS
> quando serve utilizzare qualcosa di potente ma
> "leggero".
>
> ciao Sandro
>
>


Maggiori informazioni sulla lista Gfoss