Newsgroup: it.comp.software.database
Titolo: Alternativa ad Access

Ciao a tutti.
Esiste un database desktop alternativo ad Access ?
Vorrei poter disporre di un database su file (come per i .mdb)
accessibile via ODBC.
Esiste ?
Devo sviluppare una piccola applicazione in .Net e preferirei non dover
installare su tutti i client SQL Express, MySQL ecc...
Ciao e grazie.

 
Allora SQLite va piů che bene, esiste anche una interfaccia per .Net.
http://www.sqlite.org/cvstrac/wiki?p=SqliteOdbc
http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers
Saluti  Manlio Perillo

Grazie mille, gli darò sicuramente un'occhiata.
Ciao e grazie ancora.

--------------
FIREBIRD
--------------
1 - E' un vero db server e quindi potrai usarlo anche in mutiutenza se 
servisse.
2 - Se vuoi usarlo da monopostazione il tutto e' racchiuso in una dll.
3 - Tutto il db e' contenuto in un solo file e quindi puoi trasportarlo, 
backupparlo facilmente.
4 - Esiste sia per Windows che per Linux.
5 - Il formato file contenente i dati e' identico nelle versioni Windows e 
Linux e quindi puoi semplicemente copiarlo da un sistema all'altro.
6 - Sono disponibili utility per il backup automatico anche senza 
interrompere l'accesso ai dati.
7 - Dispone di procedure per il multiversioning che semplificano e 
velocizzano le transazioni concorrenti.
8 - E' aggratisse.
9 - E' Open-Source.
10 - dispone gia' di driver odbc
11 - dispone gia' di libreria nativa per ambiente .Net
Sono le prime che mi vengono in mente. Bastano ???
Ora pero' sei OBBLIGATO ad usarlo.
Ed a supportarlo (inviando soldini e/o contributi in aiuto).
Ciao.
RobertoA

 backupparlo facilmente.
Hum un solo file per db e log ? Questo lo vedo piů come uno
svantaggio...


Why ????
Ciao
RobertoA

 svantaggio...
Il database puo' essere suddiviso in piu' file, ma il discorso rimane 
simile (i log sono sullo stesso file del db[1])
Henryx
[1] oddio, potrebbe essere anche che si trovino in RAM, ma non saprei dirlo 
con certezza

"RobertoA":

In caso di crash del disco, perdi tutto... Avendo invece i file su
due dischi, puoi contare di recuperare tutti i dati come segue:
1) Se si falla il disco del db: ultimo backup + log = dati correnti
2) Se si falla il disco del log: cambi il disco ma non perdi niente.
Chiaramente si può risolvere mirrorando il disco, anzi direi che a
questo punto è assolutamente indispensabile farlo...
Anche dal punto di vista prestazionale hai delle penalità: le
scritture su disco non possono avvenire in parallelo.
Inoltre, a causa del tutto-in-uno si avranno anche altri problemi
tutti da scoprire; ad esempio, nel caso di una select che comporti
una scansione sequenziale del file, si perderà tempo a ignorare i
dati di log. Non posso avere un efficace circular logging. Uno
shrink del file di db sarà intralciato dalla presenza dei blocchi
di log, e viceversa. L'esaurimento dello spazio su disco del file
di log causerà il blocco del db perché entrambi competono per
l'unico spazio disponibile. Si avrebbe poi un'aumentata
frammentazione dovuta al miscelamento di blocchi di log e di dati.
etc etc
In definitiva la vedo come un'architettura un po' disordinata, che
in cambio di un piccolo vantaggio immediato, pone una serie
notevole di conseguenze praticamente impossibili da rimediare.
ciao

 saprei dirlo con certezza
Un file di log in ram? E in caso di blackout?

 
Tornando ad SQLite, questi usa un file di journal quando effettua una
transazione.
Il file con il database non dovrebbe contenere log.
Saluti  Manlio Perillo

 Il file con il database non dovrebbe contenere log.
Ho dato un'occhiata al sito; le funzionalità base del motore stanno
in 150 Kb... wow davvero sorprendente in tempi in cui i giga si
sprecano.

The man with two watches ha scritto:

Uno dei pregi di SQLite è la sua semplicità.
Questo porta solo vantaggi.
Il supporto delle foreign key è al primo posto nella lista delle
funzionalità mancanti, spero che entro quest'anno vengano supportate e
senza dover complicare troppo il codice.
Saluti  Manlio Perillo

 Un file di log in ram? E in caso di blackout?
Da quello che hai esposto nel post di risposta a RobertoA, posso darti 
altre informazioni. In Firebird e' possibile, oltre che suddividere il 
database in n file, creare delle repliche parallele (i cosiddetti 
shadow), in modo da incrementare la sicurezza del database stesso. 
Inoltre, una buona politica di backup (gbak e' li apposta) permette di 
superare parecchi problemi dovuti ad un blackout/malfunzionamento. Per 
quanto riguarda i log, come ho detto prima, non so se vengono 
implementati in qualche maniera specifica (eccetto gli shadow, che devono 
essere specificati dall'utente), e l'esempio dei log in ram da me fatto 
era volto ad essere proprio quello: un esempio
Henryx

 shadow), in modo da incrementare la sicurezza del database stesso.
Ok grazie della spiegazione; ti chiedo ancora una cosetta, dato che
mi sembra che conosci il prodotto: ha un buon clustering?
Grazie ciao


Sono molto interessato alle repliche ma non le ho mai provate.
Puoi dirmi se le hai usate in qualche ambiente reale di lavoro e qual'e' la 
tua esperienza (positiva/negativa) sulle loro effettive possibilita' di 
utilizzo?
Insomma, volevo capire se magari hai avuto qualche problema col db 
principale e magari la replicati ti ha salvato oppure se le usi per 
permettere la consultazione in localita' connesse con linee lente, o altro.
Ciao e grazie 

 mi sembra che conosci il prodotto: ha un buon clustering?
Da quello che ricordo sul discorso clustering (in generale), vi erano due 
tipi di cluster implementabili: uno che sfrutta n macchine per fare il 
medesimo lavoro, e uno che permette la replicazione su n macchine in 
maniera da ottenere un rimpiazzo del database del tutto trasparente 
all'utente in caso di malfunzionamento. Qualcosa c'e' (soprattutto per il 
secondo punto, vi sono fibre, IBReplicator, e altri applicativi di cui 
ora non ricordo/conosco il nome), e qualcosa e' in sviluppo 
(
http://www.firebirdsql.org/devel/engine/roadmap2006.html
)
Henryx

 possibilita' di utilizzo?
Allora, qui devo fare necessariamente una precisazione: io non uso 
Firebird :)
Per chiarire meglio, conosco Firebird in quanto mi interessa parecchio, 
ma al lato pratico uso PostgreSQL per uso personale e Oracle/SQL Server 
per uso lavorativo. Attualmente, non uso Firebird per uso personale 
(anche se penso di svilupparci un progettino[1]) in quanto mi sono 
scontrato in alcuni problemucci:
- la creazione delle chiavi ha qualche limite (mi sembra di nome, ma non 
ricordo bene);
- finora ho sviluppato solo in Java, e il driver JDBC ha un bug 
abbastanza fastidioso nell'uso dei PreparedStatement (bug di cui ho 
eseguito anche l'apposita segnalazione su Sourceforge, basta vedere il 
link 
http://sourceforge.net/tracker/index.php?func=detail&aid=1067485
&group_id=9028&atid=109028 [2][3]);
- attualmente la versione per AMD64 e' considerata instabile.
Ovviamente nulla di irreparabile (e.g. il bug del driver JDBC non si 
presenta con gli Statement), ma allora mi fecero preferire passare a 
PostgreSQL piuttosto che perseverare su questa strada (non che l'abbia 
abbandonata completamente, ho ancora il vizio di installarlo e di 
giochicchiarci un po')
Henryx
[1] la persona di Manlio Perillo e' avvisata :)
[2] Il link probabilmente e' da ricostruire
[3] il fatto che il bug sia ancora aperto, mi e' stato indicato come 
dovuto dal fatto che gli sviluppatori tengono molto piu' in 
considerazione la mailing list piuttosto che il bug tracker di 
Sourceforge. Maggiori informazioni le puoi trovare facendo ura ricerca 
nei vecchi messaggi del gruppo, dato che ne avevo parlato (e che quella 
spiegazione mi era stata data) proprio qui

 10 - dispone gia' di driver odbc
Ora che ci penso...
La versione embedded, in 2MB (si, DUE MegaByte[1]) di DLL permette di 
fare _esattamente_ le stesse cose della versione completa, con il grosso 
vantaggio di non dover installare nulla (e il fastidioso svantaggio di 
poter lavorare con una sola sessione per volta[2]) e di integrare il 
motore nel proprio appliativo. Inoltre, tale DLL puo' essere utilizzata 
in congiunzione con il driver ODBC (ovviamente anche in questo caso si ha 
la limitazione della sessione unica), il tutto senza dover cambiare nulla 
nella logica dell'applicativo
Henryx
[1] non che la versione normale sia piu' grossa, in quanto 
l'installazione completa occupa circa 10Mb
[2] limitazione che, se non ricordo male, e' anche di SQLite

 [2] limitazione che, se non ricordo male, e' anche di SQLite
Cioè che un processo può creare una sola connessione al database?
Se è così SQLite non ha affatto questo problema.
Puoi collegarti ad un database da più processi e da più thread in uno
stesso processo.
Saluti  Manlio Perillo