[Gfoss] problemi con indici spaziali sqlite

[aperi2007]

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" <mescal72 a gmail.com 
> <mailto:mescal72 a 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.furieri a lqt.it
>     <mailto:a.furieri a 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
>
>

-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20140221/e07ba857/attachment.html>