On Sat, Dec 08, 2007 at 08:55:56PM +0100, Andrea P. wrote:
>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.
Perdonami ma non penso proprio che un db compatto java-based possa
risultare piu' veloce. Sul fatto che usando OOo venga spontaneo
utilizzare l'engine interno di OOo non ci sono dubbi, ma se ben ricordo
il quesito originale era su un oggetto non java-locked e basta farsi
un giro su google per rendersi conto che la maggioranza usa
shape e sqlite come equivalente del famigerato 'personal db' di
arc-coso. Stiamo sempre parlando di db leggeri, compatti e
trasportabili, non di efficienza.
--
Francesco P. Lovergine
La tua analisi si basa su dei presupposti giusti.
Ma e' parziale.
SQLite salva tutto in testo.
Questo significa che per cercare u numero non ne ricerca la versione binaria e compatta, la lo sviluppo in testo.
Idem per le ricerche.
Se si scende a basso livello nell'hardware della macchina.
Un conto e' fare un confronto tra numeri e un conto e' fare un confronto tra caratteri.
Gli algoritmi per il confronto tra numeri sovrastano gli algoritmi di confronto tra caratteri di parecchi ordini di grandezza.
Il che significa che anche se si ragiona di un confronto tra un motore java-based e uno c-based.
La maggiore efficienza degli algoritmi rende il primo piu' veloce.
Ciao.
On Sun, 9 Dec 2007 09:23:07 +0100, Francesco P. Lovergine wrote:
On Sat, Dec 08, 2007 at 08:55:56PM +0100, Andrea P. wrote:
>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.
Perdonami ma non penso proprio che un db compatto java-based possa
risultare piu' veloce. Sul fatto che usando OOo venga spontaneo
utilizzare l'engine interno di OOo non ci sono dubbi, ma se ben ricordo
il quesito originale era su un oggetto non java-locked e basta farsi
un giro su google per rendersi conto che la maggioranza usa
shape e sqlite come equivalente del famigerato 'personal db' di
arc-coso. Stiamo sempre parlando di db leggeri, compatti e
trasportabili, non di efficienza.
--
Francesco P. Lovergine
_______________________________________________
Prenota la tua maglietta GFOSS.it:
http://wiki.gfoss.it/index.php/Gadgets
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.com
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.