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
