Files vs. DataBases

[/dev/null]

Sto facendo un programma che ha bisogno di memorizzare un numero illimitato di oggetti...
Per farvi un esempio supponiamo che debba gestire degli utenti: ogni utente avra' il nome, il nick, l'e-mail, la descrizione, un'immagine, molti valori numerici per le sue statistiche etc etc etc...
Sono indeciso su come gestire la cosa...
Usare un database con tante colonne quanti valori sembrerebbe la cosa piu' semplice...
Io pero' ho gia' iniziato a realizzare questo programma basandolo su files: ogni utente avra' un proprio files nella directory degli utenti... Il nome dei files sara' numerico e corrispondera' all'UserID dell'utente... Quindi il file dell'utente Pippo con UID 21 sara' /utenti/21.usr...

Prima di continuare ad usare i files, o di passare ad utilizzare il DataBase vorrei sapere le prestazioni dell'uno e dell'altro...
I valori degli utenti dovranno venire modificati molto molto spesso... E spesso dovrebbe venire anche aggiunto qualche utente... Credo che per fare cio' la migliore scelta sia usare i files, ma non ne sono sicuro, e' per questo che chiedo a voi...
Inoltre i valori dovranno venire anche letti molto spesso (piu' o meno ogni quanto dovrebbero venire modificati): c'e' bisogno di leggere i valori di singoli utenti, ma anche di piu' utenti insieme o di effettuare ricerche tra i nomi e gli altri valori degli utenti... Ed ho paura che per queste cose sia meglio usare un database, dato che occorrebbe un unico accesso al file, e non uno per ogni utente...

Cosa mi consigliate di fare? Potete motivare le vostre risposte e magari se avete dei link di test su files e database postarli?

[LeleFT]

Secondo me per questo tipo di applicazioni non c'è nulla di più performante di un database. Ovviamente devo motivare la risposta:

1) Le informazioni salvate in un DBMS, generalmente, occupano meno spazio rispetto alla soluzione su files: la frammentazione dovuta ai files viene meno con le tecniche di memorizzazione del database, che, oltretutto, provvedono a "compattare" i dati per ottenere un miglior utilizzo dello spazio su disco;

2) Le letture e gli aggiornamenti sono sicuramente più performanti utilizzando un DBMS: il DBMS utilizza degli algoritmi ottimizzati per ricerche e modifiche, facendo uso di indici, strutture ad albero e quant'altro non si trova, normalmente, in un file di dati; se utilizzi i file, tutta la complessità la devi gestire tu, manualmente e, senza nulla togliere alla tua esperienza e capacità, non sempre riusciresti a trovare facilmente l'algoritmo ottimizzato.

3) La sicurezza che offre un DBMS non la si ottiene utilizzando i files: essi sono più "indifesi" contro gli errori dell'utente del PC

4) Ricerche e interrogazioni sono gestite in automatico dal DBMS, cosa che con i files non avviene: con una "semplice" query ottieni dei risultati in tempo brevissimo e senza tanta fatica (è per questo che sono nati i linguaggi dichiarativi come SQL).

5) I DBMS astraggono molto dal File System in uso: sono loro che si preoccupano della gestione del File System (ossia come memorizzare i dati fisicamente su disco); con la gestione tramite files, questo problema è a carico tuo.

Queste sono le motivazioni che porto a supporto della mia idea. Ovviamente il punto 5 potrebbe venire meno a seconda delle esigienze che hai tu, comunque, io ti ho solo proposto una linea, i sostenitori della filosofia Files-Oriented avranno, sicuramente, le loro ragioni. Avrai del materiale su cui lavorare!

Ciao.

[/dev/null]

Grazie
Per quanto riguarda la complessita' della gestione, lo spazio occupato e la sicurezza non me ne faccio un problema...
Le mie domande erano rivolte piu' che altro alle prestazioni...

I files attualmente li sto gestendo cosi': se ogni files deve contenere dieci informazioni sull'utente (nome, pass, questo e quello) i primi quaranta bytes sono occupati da dieci interi (grossi 4 bytes l'uno) che dicono a che punto si trova la data informazione...
Ad esempio se le informazioni che devo tenere sono: nome, password ed email, il primo intero punta al byte all'interno del file dove e' situato il nome... Il secondo punta alla password ed il terzo all'email...
Se io voglio conoscere la password leggo il secondo ed il terzo intero, mi sposto nel file nel punto indicato dal primo byte e leggo fino al secondo...


Credo (o almeno spero) proprio che i db siano piu' performanti ad eseguire un'operazione del genere, dato che sono fatti a posta e sono in continuo miglioramento...
Tutta via se io ho un file grosso 10 gb e voglio aggiungere un byte all'inizio (far diventare quindi il file grosso 1 gigabyte e 1 byte, appendendo un byte in cima) dovrei riscriverlo tutto sul disco aggiungendoci davanti un byte (non credo ci siano altre soluzioni, in tal caso scusate la mia ignoranza ) e questa operazione dovrebbe essere parecchio pesante; farlo con un file grosso 1kb invece sarebbe istantaneo...
Se fin qui' non ho sbagliato, mi chiedo che prestazioni possa avere un database di quelle dimensioni durante un'aggiunta o una modifca... Durante la lettura non ho dubbi che sia piu' rapido (credo che comunque dipenda anche qui' dalle dimensioni) e non ho dubbi nemmeno sul fatto che dovendo visualizzare piu' utenti in contemporanea (o fare una ricerca basata su qualche elemento diverso dall'id) in un caso (coi files) dovrei aprire file per file, mentre nell'altro (coi db) basterebbe aprire uno, e, soprattutto se gli utenti sono migliaia, nel primo caso ci devo stare un quarto d'ora...




Aspetto altri consigli

[LeleFT]

Originariamente inviato da /dev/null
Se fin qui' non ho sbagliato, mi chiedo che prestazioni possa avere un database di quelle dimensioni durante un'aggiunta o una modifca...

Anche nelle aggiunte i DB sono più performanti: come hai già detto tu, se devi aggiungere un byte in testa ad un file grosso 1 GB o grosso 1 KB le cose cambiano notevolmente. Con un DB la cosa, invece, è sostanzialmente la stessa: infatti, è sufficiente aggiungere quel byte in coda ed andare a modificare solamente gli indici, ossia una struttura ad albero, apportando una sola modifica in un certo punto dell'albero. Come tu ben saprai, le strutture dati come gli alberi (in particolar modo RB-Tree), permettono una notevole velocità in ricerca dei dati e questo porta a notevoli prestazioni anche in aggiunta dei dati: è sufficiente ricercare il punto nell'albero in cui la chiave inserita deve "posizionarsi" (il nodo, in sostanza) e lì aggiungere un puntatore al blocco del file che lo contiene. Queste operazioni il DBMS le fa in automatico e utilizzando algoritmi ottimizzati.

Come te, però, sono curioso di vedere quali sono le ragioni per preferire i files ad un DB. Spero che qualcuno voglia dire la sua, dato che queste cose mi interessano enormemente.


Ciao.

[/dev/null]

Originariamente inviato da LeleFT
Anche nelle aggiunte i DB sono più performanti: come hai già detto tu, se devi aggiungere un byte in testa ad un file grosso 1 GB o grosso 1 KB le cose cambiano notevolmente. Con un DB la cosa, invece, è sostanzialmente la stessa: infatti, è sufficiente aggiungere quel byte in coda ed andare a modificare solamente gli indici, ossia una struttura ad albero, apportando una sola modifica in un certo punto dell'albero. Come tu ben saprai, le strutture dati come gli alberi (in particolar modo RB-Tree), permettono una notevole velocità in ricerca dei dati e questo porta a notevoli prestazioni anche in aggiunta dei dati: è sufficiente ricercare il punto nell'albero in cui la chiave inserita deve "posizionarsi" (il nodo, in sostanza) e lì aggiungere un puntatore al blocco del file che lo contiene. Queste operazioni il DBMS le fa in automatico e utilizzando algoritmi ottimizzati.

Sospettavo una cosa del genere... In pratica un database e' come un mini filesystem...
Ho chiarito i miei dubbi DB, a me!

Come te, però, sono curioso di vedere quali sono le ragioni per preferire i files ad un DB. Spero che qualcuno voglia dire la sua, dato che queste cose mi interessano enormemente.


Ciao.

Io ho scelto di usare i files piu' che altro perche' il programma sara' piu' portatile, dato che usando i database serve che la macchina su cui verrato il programma l'abbia installato...
Inoltre, con database come MySQL (l'unico che ho usato qualche volta ) e necessario avere nome e password di un utente mysql che abbia i privilegi per creare databases etc... A cose normali quindi solo l'amministratore di sistema potra' usare un software basato su database...

Grazie per avermi chiarito diversi dubbi... Ora non mi resta che scegliere il database da usare...

[unomichisiada]

...usando i database serve che la macchina su cui verrato il programma l'abbia installato...
Inoltre, con database come MySQL (l'unico che ho usato qualche volta ) e necessario avere nome e password di un utente mysql che abbia i privilegi per creare databases etc... A cose normali quindi solo l'amministratore di sistema potra' usare un software basato su database...

Premesso che riguardo alle prestazioni sono convinto anche io che un database sia più performante (nonostante la mia ignoranza in questo campo) è interessante il problema "quotato" sopra che dev ha esposto e soprattutto sarebbe interessante se qualcuno avesse una soluzione anche a questo,mi interesserebbe conoscerla.Ad esempio qualcosa di alternativo a MySql che non presenti questi svantaggi.

[LeleFT]

Diciamo che non tutti i DBMS richiedono l'installazione del DBMS stesso per l'utilizzo del programma. Prendo un esempio: Microsoft ACCESS. A prescindere dalle prestazioni del DBMS, non è necessario possedere Access per utilizzarne un DB in una applicazione. E' sufficiente disporre del file MDB e, probabilmente, di qualche driver Microsoft. Conosco un gestionale (pessimo, per dire la verità) che fa uso di un database Access per memorizzare le informazioni relative a Piano dei Conti, Fatturazione, Anagrafica Clienti e quant'altro e non è necessario avere installato Access per il suo utilizzo: il programma (sviluppato in VB, oltretutto) accede al file MDB in modo autonomo (appoggiandosi, probabilmente a DLL necessaire) e lo aggiorna/interroga a dovere.

Questo, ovviamente, non vale per DBMS come MySQL. Senza di esso non credo si possa costruire una applicazione indipendente che ne faccia uso, ma altri sistemi credo che possano funzionare. (Se non erro, Delphi ha un suo DBMS, ma non vorrei dire castronate, ed i programmi che lo utilizzano non necessitano della sua installazione indipendente).

Comunque, esistono anche alternative a questo: un DB MySQL può sempre essere condiviso in rete e quindi è possibile costruire una applicazione che si collega ad un DB in rete e ci lavora, senza che il cliente dell'applicazione abbia installato MySQL (sono, ovviamente, soluzioni estreme e non sempre praticabili).


Ciao.

[/dev/null]

Vabbe', a quel punto potrei usare i files... Invece che come stavo facendo mi basta unirli tutti in un unico file: il database
Mi ero informato per le prestazioni, non per tenere scegliere se avere un unico file o se averne molti sparpagliati in una directory... E vorrei poter supportare illimitati utenti: non vorrei cha al raggiungimento di una certa cifra tutto iniziasse a barcollare...

Inoltre questo programma e' finalizzato principalmente a girare sotto Linux...