Newsgroup: it.comp.os.linux.development
Titolo: immagazzinare dati: come?

Avrei un piccolo problema: l'applicazione su cui sto lavorando (in C e
GTK) necessita di molti dati, anche da dover modificare piu' volte
durante l'esecuzione o per cui e' richiesto un rapido accesso diretto.
Avevo pensato di appoggiarmi ad un database (MySQL) per gestire tutti i
dati, ma mi rendo conto che effettivamente si tratterebbe di una
soluzione affrettata: i dati non sono poi cosi' *tanti* da giustificare
la presenza di un ingombrante database...
Allo stesso modo, utilizzare uno o piu' files da parsare ogni volta e da
modificare al volo mi sembra alquanto lento: praticamente ad ogni azione
dell'utente ci sarebbe da prendere o cambiare qualcosa tra i dati...
Quale soluzione mi suggerite? Esiste qualche modo per utilizzare dei
normali files in modo un po' piu' dinamico dei soliti "leggi" e
"scrivi", che oltretutto presentano il grosso limite di non poter andare
a leggere e scrivere in un certo punto del file direttamente senza
passare per tutte le altre righe?
TIA
--
web 
http://madbob.homelinux.com
mail bob4mailC...@CANCELLAMIk.st
BrainTop Project maintainer
http://braintop.sourceforge.net
Inviato da 
www.mynewsgate.net

 dell'utente ci sarebbe da prendere o cambiare qualcosa tra i dati...
berkley db?
-- 
cat: .signature: No such file or directory

 passare per tutte le altre righe?
A parte l'idea di usare XML, potresti usare il Berkeley DB. Entrambe
le soluzioni hanno dei vantaggi e degli svantaggi.
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)                 [ 
http://www.emmanuelebassi.net
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 la presenza di un ingombrante database...
Se puoi tenere tutta la baracca in memoria fai prima a fare un
(de)serializzatore.
Se ti piace l'sql c'è sqlite. Oppure firebird embedded (mai provato).
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! Take It All, Our Gold, Our Homes, Our Life, But We Didn't Kill 
	    Your Christ! !>- Blind Guardian - The Script For My Requiem

 le soluzioni hanno dei vantaggi e degli svantaggi.
non credo che le prestazioni di xml siano così spinte....

 non credo che le prestazioni di xml siano così spinte....
I tempi di parsing sono *molto* buoni, e sono limitati al caricamento
del file, dove *comunque* si perde del tempo per l'IO; poi, si può
mantenere l'intero albero DOM in memoria, ed eseguire il dumping a cose
fatte.


 fatte.
mmmm... però hai sempre un mega vettore di char da parserizzare, anche se
sta in memoria. E questo è lento.

 
Ho dato uno sguardo al sito di riferimento (
http://www.sleepycat.com/products/db.shtml
 ), ma in tutta sincerita' non
ho ben capito di cosa si tratti...
Non e' un server, ma una libreria; non e' nulla di simile a SQL, e
permette a diverse applicazioni di scambiarsi dati...
In poche parole: *dove* vengono immagazzinate le informazioni e *in che
modo* possono essere recuperate / inserite???


 TIA
L'idea dei vecchi file sequenziali, quelli che si usavano negli anni '70
prima dell'avvento dei RDBM, l'hai presa in considerazione? 
Per specifici utilizzi (attorno al mega di dati) è ancora molto valida ed
io la uso spesso.
--
ciao Max

 senza passare per tutte le altre righe?
Prova a cercare qualcosa su SQLite... (
www.sqlite.org
).
Riporto dal sito: 
"SQLite is a small C library that implements a self-contained,
embeddable, zero-configuration SQL database engine."
Praticamente hai un database, come fosse mysql, in un file e ci si può
accedere attraverso comandi SQL. Da quel poco che l'ho usato (in Perl,
però) dovrebbe essere abbastanza performante...
Ciao,
-- 
+--------+ | ASCII ribbon campaign ( ) | 
www.autistici.org/kral
|  kral  | |  - against HTML email  X  |
+--------+ |              & vCards / \ | my gpg id = 0x7C946947


Beh, fortunatamente da piu' di 20 anni abbiamo parser in tempo 
lineare... ;)))
C'e' cmq da considerare che pure un db ha tutta una serie di operazioni 
di bookkeeping non indifferenti. Credo che il piu' veloce tra i due 
modelli sia determinato dal genere di uso che si vuol fare dei dati.
Effettivamente, di fronte all'uso descritto, non saprei quale dei due 
consigliare, anche se forse un berkley ad occhio mi sembra migliore.
-- 
Mat/tia Belletti - Undergraduate student @ 
cs.unibo.it
ICQ: 33292311    - email: 
mbel...@cs.unibo.it
IRC: RedGlow     - site(s): 
http://www.cs.unibo.it/~mbellett
Linux registered user 299762 @ Linux registered machine 213003

 sta in memoria. E questo è lento.
In C? Non direi: il parsing di un file di medie dimensioni impiega pochi
millisecondi; altrimenti, qualunque browser sarebbe inutilizzabile, no?
E, comunque, se questo delay si perde nei tempi di caricamento del
programma, non si nota affatto dal "lato utente".
Per mantenere i file XML di dimensioni ragionevoli (e parlo di qualche
MB), si può sempre spezzare il tutto e mappare una porzione di
filesystem con un filesystem virtuale, e.g. quello che fa GConf.


 modo* possono essere recuperate / inserite???
Viene usato un file (binario) in cui viene eseguito il dump di un
database in memoria. Le primitive di accesso al database sono fornite da
una libreria, appunto, che ti permette di recuperare il dump e di
ricostruire il database attraverso le sessioni, oppure da differenti
istanze. Non è un (R)DBMS, e non usa SQL.


 filesystem con un filesystem virtuale, e.g. quello che fa GConf.
!?!? spiega spiega, per piacere?

 istanze. Non è un (R)DBMS, e non usa SQL.
Dovrebbe essere piu` una tabella di hashing su un file che un DB. I
dati vengono acceduti tramite una chiave (che puo` essere numerica ma
anche alfanumerica).
E` ottimo per ricerche veloci basate su chiave ma non per operazioni di
join tipiche dei db o per ricerche su chiavi diverse da quella base.
Bye.

 anche alfanumerica).
Ho solo letto velocemente la documentazione, non l'ho mai effettivamente
usata questa libreria (un po' perché le strutture dati "dumpate" su file
senza avere dietro uno standard mi hanno sempre preoccupato, per quanto
riguarda portabilità e compatibilità in avanti, perlomeno).


 !?!? spiega spiega, per piacere?
GConf usa una porzione di filesystem (nel backend XML) che mappa le
directory di un path, ad esempio:
	/desktop/gnome/applications/window_manager
In directory vere e proprie:
	$(RESOURCE)/desktop/gnome/applications/window_manager
Dove $(RESOURCE) è una locazione definita dall'utente, ad esempio:
	$(HOME)/.gconf2/
A questo punto, le chiavi nella directory di cui sopra sono salvate in
un file XML; così facendo, la dimensione dei file XML da interpretare è
ridotta alle coppie chiave/valore, e non ad un'intero percorso, come:
	<desktop>
	  <gnome>
	    <applications>
	      <window_manager>
	        ...
		<key name="current">
		  <value type="string">/usr/bin/metacity</value>
		  ...
		</key>
		...
	...
I backend vengono caricati all'avvio del demone, e il database delle
opzioni viene costruito in memoria (poi viene condiviso tutto tramite
CORBA, ma questo è un altro discorso). Le coppie chiave/valore vengono
recuperate in maniera del tutto trasparente usando il path della chiave:
sta ai backend sapere come recuperare l'informazione (un backend a un
RDMBS potrebbe usare una query SQL, ad esempio).
Stavo pensando di usare lo stesso meccanismo per una libreria per il
Personal Information Management.


 Ho solo letto velocemente la documentazione, non l'ho mai effettivamente
Stessa cosa che ho fatto io, non intendevo criticare la tua risposta, solo
precisare un pochino. :)
La sensazione di "hash table" mi e` venuta in mente proprio leggendo il
discorso sull'id.
Per esempio so che quel tipo di db vengono usati per le password (per
esempio pure-ftpd o postfix) dove la chiave e` appunto lo username e il
contenuto e` la password e i vari dati (home, shell, scadenza, ...).
Bye.

 Inviato da 
www.mynewsgate.net
Secondo me la prima idea è la migliore, se poi di MySQL usi una versione
"più magra" tipo la 3.23.49 anziche le ultime con transazioni ecc., è molto
veloce e sempre sicuro. In più se dovessi usarlo anche su Windows il DB non
ti creerebbe nessun problema; io l'ho fatto e sono contento.
-- 
enzo
en...@sennasoftwareclub.org
url: 
www.sennasoftwareclub.org



Ma dai! Un DB come MySQL è molto meglio e ti permette molte più cose
inoltre, in C puoi farci delle stored procedure evitando di scrivere 100
volte lo stesso codice. Certo se non lo conosci devi un po studiarci, ma
non più di tanto.


Roberto -MadBob- Guido wrote:

Io userei MySQL, ma se i dati non sono molti e la memoria è suffucente,
fatti delle arrey.


non più di tanto.
Non è detto. In certe situazioni è meglio altro. Parlando di mysql, in
moltissime situazioni è meglio altro. 

 non più di tanto.
Non è assolutamente vero! 
Ad esempio quando ho dati finiti, ovvero so che  userò solo un
determinato numero di record, preferisco usare un file sequenziale è
molto più veloce di "qualsiasi" database in quanto si fa sempre degli
accessi diretti in base alla posizione del record. 
In fin dei conti non è altro che un array bidimensionale scritto sul disco!
Il fatto di riscrivere codice non è pertinente, quello dipende sempre
dallo ... scrittore!
--
ciao Max

 non più di tanto.
Non è assolutamente detto che sia possibile tirarsi dietro un server
"full fledged", sia per vincoli di software che per vincoli di
hardware.
Se i dati da inserire, poi, non richiedono espressamente un DBMS,
allora è inutile portarsene dietro uno a traino solo per un programma.


 
Mumble mumble... Si, credo che mi possa bastare... Devo ancora dare una occhiata
approfondita alla documentazione, tanto per capire se una soluzione di questo
genere possa andar bene, ma, da quanto ho letto nei vari posts di questo thread,
credo che offra tutto cio' di cui avrei bisogno (cioe': troppo poco per un
database SQL, troppo per un semplice file con dati sparsi da parsare)...
Faro' sapere :-)


 Ce l'hai già: si chiama DOM.
ho capito.
si impara sempre qualcosa. :-)

 giustificare la presenza di un ingombrante database...
Hai pensato a sqlite? 
http://www.sqlite.org
Gratuito (public domain), motore sql, e' una libreria, quindi niente
connessioni client-server-chealtro, usa dei file locali
all'applicazione: non devi installare niente in piu' oltre alla tua
applicazione (e' oltremodo microscopica, quindi la puoi anche inglobare
nel tuo progetto)
-- 
()_() | Always keep the Titanic in mind when I talk about  | +----
(°.°) | security or safety, meaning that nothin is         | +---+
'm m' | fully secure.                                      |  O  |
(___) |              raffaele punto salmaso presso libero punto it
GPG fingerprint 1CF5 51D4 E528 EB87 9977  B277 BE8C BF1E 620C 40ED

 
Mannaggia a te: proprio ora che ero stato convinto ad usare il Berkeley te
ne salti fuori con questa altra soluzione, che sembra essere altrettanto
valida! Ora mi hai fatto tornare i dubbi :-) !
Specifico meglio quali sono le mie esigenze, cosi' che sia piu' facile
consigliarmi: devo indicizzare una serie di gruppi, entro cui stanno dei
riferimenti a files sparsi sul filessystem (ognuno dei quali deve poter
essere anche eventualmente relazionato ad una applicazione per
l'elaborazione del file stesso) e delle stringhe. In futuro, probabilmente
dovro' aggiungere in tali gruppi anche altri sottogruppi che possano
contenere dati di natura diversa.
Alla luce dei suggerimenti arrivati sinora, ho pensato di creare un unico
file-database per Berkeley (in futuro eventualmente frazionabile, un file
per ogni macro gruppo) strutturato piu' o meno cosi':
chiavi:              dati:
_NOME          gruppo1
_NOME          gruppo2
_gruppo1_f     /path/file1/gruppo1
_gruppo1_f     /path/file2/gruppo1 | applicazione
_gruppo2_f     /path/file1/gruppo2
_gruppo2_s     stringa1delgruppo2
_gruppo1_f     /path/file3/gruppo1
..
L'ordine dei files e delle stringhe non ha importanza.
Devono poter essere eliminati e aggiunti elementi (files e nuove stringhe,
ma anche gruppi) in maniera abbastanza dinamica, e, con l'utilizzo di un
cursore in un Btree (mi riferisco al Berkeley) dovrebbe essere tutto
abbastanza semplice...
Alla luce di questi maggiori dettagli, ci sono ulteriori suggerimenti, sia
per l'adozione di una libreria piuttosto che un'altra o di un sistema
migliore per indicizzare i dati?


gabriele renzi wrote:

Scusa se non ho risposto prima ma al venerdì mi allontano dal pc.
Quanto dici è sicuramente vero, ma tieni presente che nel messaggio
originario Roberto diceva:
((Avrei un piccolo problema: l'applicazione su cui sto lavorando (in C e
GTK) necessita di molti dati, anche da dover modificare piu' volte
durante l'esecuzione o per cui e' richiesto un rapido accesso diretto.))
Se sapesse quanti dati gestire e fosse sicuro che il loro numero non cambia,
può farsi anche delle variabili dimensionate. Mi sembra però, senza offesa,
che abbia cominciato a costruire la casa senza preoccuparsi delle
fondamenta e in questo caso, se non sà quanto deve gestire, secondo me è
meglio che usi un DB. Che poi usi MySQL, PostGress o altro DB, è un'altro
discorso, l'importante è che decida se usare un DB o meno. Io propendo per
il DB.  
