<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><br>
Non dimentichiamo che è possibile fare dei bei casini anche su
oracle e su postgres.<br>
<br>
Ad esempio, su oracle non è cosi' infrequente che un applicativo
di caricamento disabiliti tutti i constraints <br>
per riuscire a caricare i dati.<br>
Il punto è che poi deve ricordarsi (l'applicativo) di
riabilitarli.<br>
Il che non è detto, ma non è neanche detto che una volta
riattivati, i dati che si sono insertii ci restino.<br>
:)<br>
<br>
Non è qui che si gioca la differenza tra un dbms e uno spatialite.<br>
La vera differenza è nel fatto che un db spatialite è tutto
racchiuso su un file che è del codice binario.<br>
<br>
Se uno prende un editor esadecimale e ci scrive a casaccio dentro
, lo rovina sicuramente, non ci sono trigger o foreign-key che
tengano.<br>
Al posto dell'editor esadecimale, ci puo' stare anche un codice
eseguibile che scriva roba in modo piu' o meno errato.<br>
Il succo è lo stesso.<br>
<br>
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.<br>
<br>
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...<br>
Mentre lo sqlite è fisicamente raggiungibile.<br>
<br>
E' qui la differenza vera.<br>
<br>
E' lo svantaggio di spatialite/sqlite,<br>
ma è anche il suo vantaggio.<br>
Perche' consente di funzionare senza doversi connettere in remoto
con un dbms.<br>
<br>
<br>
A.<br>
<br>
On 21/02/2014 14:29, G. Allegri wrote:<br>
</div>
<blockquote
cite="mid:CAB4g1=xDH5zD2k+Kt6aqx3-He1uEOCF0m2XAXp57fMj10ivvzQ@mail.gmail.com"
type="cite">
<p dir="ltr">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. </p>
<p dir="ltr">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. </p>
<p dir="ltr">giovanni</p>
<div class="gmail_quote">Il 21/feb/2014 14:21 "Luca Lanteri" <<a
moz-do-not-send="true" href="mailto:mescal72@gmail.com">mescal72@gmail.com</a>>
ha scritto:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">OK, grazie mille dell'analisi approfondita che
adesso andrò a leggermi e a provare con attenzione.
<div>
<div>A questo punto però vi chiedo una cosa più generica.
Come procede lo sviluppo di spatialite ? Quanto sta
investendo la comunità su SL ? </div>
<div><br>
</div>
<div>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.</div>
<div>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à.</div>
<div>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.</div>
<div><br>
</div>
<div class="gmail_extra">grazie </div>
<div class="gmail_extra">>L<</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Il giorno 21 febbraio 2014
13:16, <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:a.furieri@lqt.it" target="_blank">a.furieri@lqt.it</a>></span>
ha scritto:<br>
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>On Fri, 21 Feb 2014 13:09:54 +0100, G. Allegri
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
Piccole note:<br>
<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">INSERT
INTO test (id, geom4326) VALUES (NULL,
MakePoint(42.11,<br>
11.41, 4326));<br>
</blockquote>
<br>
</div>
<div>
Intendevi scrivere<br>
INSERT INTO test (*geom3003*, geom4326) VALUES
(NULL, MakePoint(42.15,<br>
11.45, 4326));<br>
<br>
?<br>
<br>
</div>
</blockquote>
<br>
no, proprio come ho scritto: il NULL inizializza la
Primary Key autoincrement,<br>
geom3003 non viene neppure citata di striscio e
quindi assumera' il<br>
default value (cioe' NULL)
<div><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">conseguenza
naturale e inevitabile del fatto che la catena
dei trigger<br>
è depth-first.<br>
<br>
</blockquote>
<br>
</div>
e questo conferma definitivamante che ha piu' o meno
lo stesso livello<br>
di sicurezza intrinseca come maneggiare della
nitroglicerina a ruota<br>
libera ;-)<br>
<br>
ciao Sandro<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>