[Gfoss] Open-Office e sistemi GIS

[Andrea P.]

>Sqlite e' brutto? E' portabile, multipiattaforma ed ha binding per diversi linguaggi. Non e' una scheggia, ma
>non mi aspetto da un sistema di quel genere che lo sia. 

SQLite e' un prodotto differente.

Esso si rivolge a piccoli applicativi , ove non ci si preoccupa troppo della portabilita'.

SQLite e' lento perche' tratta tutto come stringhe (numeri compresi), questo casua anche una maggiore occupazione di spazio.
Questo lo porta anche ad avere una sintassi leggermente differente dallo standard.

Non che lo conosca bene, ma queste considerazioni si capiscono guardando le sue specifiche.

Ad esempio, dalla documentazione saltano subito all'occhio questi esempi:
Due esempi riportati in documentazione come casi validi.

CREATE TABLE t1(a INTEGER UNIQUE);     
INSERT INTO t1 VALUES('0');               (notare gli apici)

CREATE TABLE t2(b TEXT UNIQUE);
INSERT INTO t2 VALUES(0);  (notare la mancanza di apici)

Si capisce subito che sqlite non si pone troppi problemi nel controllo della sintassi.

Questo comporta degli indubbi vantaggi. Le cose si fanno in fretta e si puo' anche tirare via tanto funziona comunque.

Pero' se poi si deve spostare l'applicativo fatto su un sistema DB un pochino piu' esigente (postgres) probabilmente si avrebbero dei problemi.

Questo e' un dubbio ricorrente quando si sceglie un DB. 
E' meglio un db che mangia di tutto senza fiatare , o un db pignolo che segnala subito come errore un qualcosa che non e' proprio corretto ?

Potrei sbagliarmi, ma credo che questo dualismo si riproponga anche tra postgres (molto fiscale ed esigente sul rispetto dei tipi)
e mysql (di bocca buona e qualunque cosa gli passi cerca di accomodarlo nei campi in qualche maniera).

Comunque:
il mio intervento era per sottolineare un fatto:
nel caso di OpenOffice (un prodotto verso cui , come ente, ci stiamo spostando) ha un DB integrato basato su hsqldb.
E' vero che si puo' appoggiare anche ad altri prodotti DBMS, ma il db embedded e' hsqldb e quindi e' inevitabilmente in prima fila nell'utilizzo.

Per cui il db utilizzato e' un DB che funziona esclusivamente sotto java e con driver jdbc.
Nel momento in cui ci si deve spostare da Java per una qualsiasi ragione, ecco che non si puo' piu' colloquiare con il DB hsqldb perche' non ci sono drivers 
disponibili in altri linguaggi.

Per la verita' ne esiste uno, un gateway tra jdbc e odbc.
Lo ha scritto una ditta che a quanto pare si e' studiata per bene il codice e lo ha sviluppato.
Peccato che lo venda e neanche a poco, visto che per una licenza di un driver hsqldb per odbc vuole svariate migliaia di sterline  per una licenza internet.
Si tratta di un driver che gira su windows, ma anche su Linux.
Perche' anche su linux se si vuole usare hsqldb o si conosce il java o si e' tagliati fuori.

Questo e' un peccato perche' taglia le gambe a chiunque non dispone di conoscenze java.

E' infatti facile prevedere che usando Open-Office e volendo sviluppare applicativi che si basino sul suo DB si finisce per ricorrere a java volendo rimanere 
nel gratuito, e quindi a scartare ogni altra soluzione che non si basi su tale linguaggio.

Per me che pure conosco e uso il java, ma quando posso preferisco usare il C++ non e' una gran bella situazione.

Sigh.

Andrea.