Non dimentichiamo che è possibile fare dei bei casini anche su oracle e
su postgres.
Ad esempio, su oracle non è cosi' infrequente che un applicativo di
caricamento disabiliti tutti i constraints
per riuscire a caricare i dati.
Il punto è che poi deve ricordarsi (l'applicativo) di riabilitarli.
Il che non è detto, ma non è neanche detto che una volta riattivati, i
dati che si sono insertii ci restino.
:)
Non è qui che si gioca la differenza tra un dbms e uno spatialite.
La vera differenza è nel fatto che un db spatialite è tutto racchiuso su
un file che è del codice binario.
Se uno prende un editor esadecimale e ci scrive a casaccio dentro , lo
rovina sicuramente, non ci sono trigger o foreign-key che tengano.
Al posto dell'editor esadecimale, ci puo' stare anche un codice
eseguibile che scriva roba in modo piu' o meno errato.
Il succo è lo stesso.
Anche su oracle se avessi accesso al filesystem dove stanno i datafile
di oracle e ci vado a scrivere con un editor esadecimale valori a
casaccio ottengo il medesimo risultato.
Quindi la grande differenza che ha spatialite rispetto a un dbms
tradizionale (come oracle e postgres) è che il file dove ci sta il dato
non è fisicamente raggiungibile su postgres/oracle perche' relegato su
una macchina diversa con cui si colloquia remotamente con comandi
insert/delete/update etc...
Mentre lo sqlite è fisicamente raggiungibile.
E' qui la differenza vera.
E' lo svantaggio di spatialite/sqlite,
ma è anche il suo vantaggio.
Perche' consente di funzionare senza doversi connettere in remoto con un
dbms.
A.
On 21/02/2014 14:29, G. Allegri wrote:
Lascio la risposta a Sandro, ma permettimi di dire che il punto è far
sì che gli strumenti, delegati a gestire un db Spatialite, siano fatti
in modo da assicurare la corretta gestione di tutti gli aspetti che
vanno maneggiati con cura.
Spatialite (Sqlite) sono strumenti raffinatissimi, con uno sviluppo
gestito con tutti i crismi per garantire sicurezza e affidabilità. Ciò
non toglie che possa essere usato (inconsapevolmente) male.
giovanni
Il 21/feb/2014 14:21 "Luca Lanteri" <mesca...@gmail.com
<mailto:mesca...@gmail.com>> ha scritto:
OK, grazie mille dell'analisi approfondita che adesso andrò a
leggermi e a provare con attenzione.
A questo punto però vi chiedo una cosa più generica. Come procede
lo sviluppo di spatialite ? Quanto sta investendo la comunità su SL ?
Io ho iniziato a lavorarci da poco e mi è sembrato uno strumento
assolutamente fondamentale e dalle ampie potenzialità. Anche con
le mie scarse capacità grazie a SL sono riuscito a risolvere
parecchi dei problemi.
Tempo addietro si parlava di SL come dello shapefile del futuro,
ed in effetti le potenzialità ci sono, però a leggere questo
treadh mi viene un po' di depressione. Insomma, utilizzare SL
sembra molto più complicato di quello che pare a prima vista e ci
sono risvolti non da poco da tener conto. In diversi ambiti
lavorativi non posso permettermi di maneggiare nitroglicerina o
scalare ad ampia quota, devo affidarmi alla sicurezza e
all'affidabilità.
Se esiste un forte interesse da parte della comunità tutto questo
è sorpassabile e per me SL rimane uno strumento su cui investire.
In lista però leggo poco o niente sul futuro di SL, da qui la mia
cursiosità di saperne di più da parte di chi sta dietro allo sviluppo.
grazie
>L<
Il giorno 21 febbraio 2014 13:16, <a.furi...@lqt.it
<mailto:a.furi...@lqt.it>> ha scritto:
On Fri, 21 Feb 2014 13:09:54 +0100, G. Allegri wrote:
Piccole note:
INSERT INTO test (id, geom4326) VALUES (NULL,
MakePoint(42.11,
11.41, 4326));
Intendevi scrivere
INSERT INTO test (*geom3003*, geom4326) VALUES (NULL,
MakePoint(42.15,
11.45, 4326));
?
no, proprio come ho scritto: il NULL inizializza la Primary
Key autoincrement,
geom3003 non viene neppure citata di striscio e quindi
assumera' il
default value (cioe' NULL)
conseguenza naturale e inevitabile del fatto che la catena
dei trigger
è depth-first.
e questo conferma definitivamante che ha piu' o meno lo stesso
livello
di sicurezza intrinseca come maneggiare della nitroglicerina
a ruota
libera ;-)
ciao Sandro
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013
