>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.
_______________________________________________
Prenota la tua maglietta GFOSS.it:
http://wiki.gfoss.it/index.php/Gadgets
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[email protected]
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
