[JAVA] Quale database scegliere...

[trusthat]

Salve a tutti,
siccome sono da poco nel mondo di java vorrei sapere, nella creazione di gestionali qual'è il database più adatto?
Provengo da visual basic..quindi non nascondo che sono abituato con Access.
Grazie MIlle

[kuarl]

dipende dal tipo di database che cerchi, se ne cerchi uno simile ad access, cioè uno embedded, io ho usato hsqldb.org, che è il database di openoffice 2.0

Mi sono trovato abbastanza bene, è scritto completamente in java quindi non avrai problemi di portabilità.

Se invece cerchi un database server, ce ne sono molti ma dipende dalla piattaforma, potrei consigliarti mysql perché gira ovunque e non costa niente, ma la scelta è comunque molto ampia

[unomichisiada]

Originariamente inviato da kuarl
dipende dal tipo di database che cerchi, se ne cerchi uno simile ad access, cioè uno embedded, io ho usato hsqldb.org, che è il database di openoffice 2.0

Mi sono trovato abbastanza bene, è scritto completamente in java quindi non avrai problemi di portabilità.

Se invece cerchi un database server, ce ne sono molti ma dipende dalla piattaforma, potrei consigliarti mysql perché gira ovunque e non costa niente, ma la scelta è comunque molto ampia

Ciao supporta la concorrenza questo hsqldb ?Io conosco Mckoy e Firebird Embedded ma entrambi non la supportano. I database possono essere acceduti da una sola applicazione per volta ed anche dauna sola istanza della stessa applicazione. Purtroppo questa a seconda delle situazioni è una limitazione enorme, che rende queste soluzioni improponibili.

[alka]

Originariamente inviato da unomichisiada
Purtroppo questa a seconda delle situazioni è una limitazione enorme, che rende queste soluzioni improponibili.

Non per niente di tratta di soluzioni "embedded".

Se esiste la necessità di rendere disponibile un database a più utenti, usando FireBird si ricorre all'edizione SuperServer al posto della versione Embedded che non deve essere considerata come una edizione "file based" del database (quindi, con una gestione di lock e altre casistiche).

Bisognerebbe almeno sapere quale tipologia di applicazioni ci si sta apprestando a realizzare...

[unomichisiada]

Originariamente inviato da alka
Non per niente di tratta di soluzioni "embedded".

Se esiste la necessità di rendere disponibile un database a più utenti, usando FireBird si ricorre all'edizione SuperServer al posto della versione Embedded che non deve essere considerata come una edizione "file based" del database (quindi, con una gestione di lock e altre casistiche).

Beh allora supponi di avere una situazione in cui hai bisogno di tutte le capacità di multiutenza fornite da un normale DBMS ma hai anche la necessità di fornire all'utente un pacchetto pronto all'uso, senza doverti assicurare che lui sia in grado di configurare ed installare correttamente un dbms. O ancora, supponi di dover installare il tuo programma lato server su una macchina che ti fornisce l'hosting (quindi fuori dal tuo controllo) che non fornisce alcun servizio DBMS. Non sarebbe forse una bella cosa avere una semplice libreria (dll, file jar o quello che è a seconda del linguaggio) da poter mettere in una cartella della tua applicazione e distribuire con essa, in grado di supportare richieste contemporanee da più thread (uno per gestire ogni client della tua applicazione lato server)?

Bisognerebbe almeno sapere quale tipologia di applicazioni ci si sta apprestando a realizzare...

Ehm... Non ho capito se me la devo prendere, io ovviamente SO dove voglio arrivare quando mi appresto a scrivere un'applicazione.

[alka]

Originariamente inviato da unomichisiada
Beh allora supponi di avere una situazione in cui hai bisogno di tutte le capacità di multiutenza fornite da un normale DBMS [...]

Se parliamo di database di tipo client/server, come FireBird, il loro utilizzo in ambito multiutenza ha senso solo in ambito client/server; a nulla servirebbe introdurre meccanismi per poter consentire l'uso di un "database embedded" da parte di più utenti quando questo panorama si gestisce correttamente installando un semplice server.

FireBird è ottimizzato per client/server, non è un database "file based", pertanto è uno spreco (ammesso che sia possibile) introdurre funzionalità multiutenza perchè qualcuno, avendo a disposizione un DBMS client/server, vuole usare in multiutenza la versione "embedded".

Rettifico, non è uno spreco, non ha semplicemente senso.

Altri formati esclusivamente "file based", come Access, non prevedono interazioni tra un client ed un server, non esiste quindi un protocollo che deve essere rispettato come avviene per FireBird in cui queste entità esistono ma in cui non sono contemplate meccaniche di gestione dei lock, non utilizzabili in ambito client/server e non introducibili per motivi di compatibilità nella versione "embedded" in quanto questa deve essere pienamente sostituibile alla versione client "classica" che accede ad un server, anche locale, al posto di un file fisico direttamente.

Riassumendo, se l'utente vuole un prodotto pronto all'uso e adopera FireBird, in locale può usare la versione "embedded"; non ha senso ed è uno spreco avere funzionalità multiutente nella versione "embedded": se vi è la necessità di lavorare con più utenti, il signor cliente si installa la versione client/server, adoperabile senza apportare modifiche all'applicazione esistente (salvo indicare un percorso logico relativo al server piuttosto che un percorso fisico).

Originariamente inviato da unomichisiada
Ehm... Non ho capito se me la devo prendere, io ovviamente SO dove voglio arrivare quando mi appresto a scrivere un'applicazione.

Mi riferivo all'autore originale della discussione.

Chiedere quale database scegliere senza indicare cosa ci deve fare, di fatto, permette a chiunque di scrivere il proprio formato o DBMS preferito senza aggiungere argomentazioni in quanto... non c'è nulla da argomentare: non è chiaro quali sono le specifiche, quindi vanno bene tutti.

Si parla genericamente di "gestionali", ma ne esistono di vario tipo. Ipotizzo qualche scenario: si deve avere anche un accesso via Web o un'interazione con siti e servizi esterni? E' necessario il multipiattaforma?

Se l'autore è ancora interessato a questa discussione, dovrebbe rispondere.

Ciao!

[unomichisiada]

Originariamente inviato da alka
Se parliamo di database di tipo client/server, come FireBird, il loro utilizzo in ambito multiutenza ha senso solo in ambito client/server; a nulla servirebbe introdurre meccanismi per poter consentire l'uso di un "database embedded" da parte di più utenti quando questo panorama si gestisce correttamente installando un semplice server.

FireBird è ottimizzato per client/server, non è un database "file based", pertanto è uno spreco (ammesso che sia possibile) introdurre funzionalità multiutenza perchè qualcuno, avendo a disposizione un DBMS client/server, vuole usare in multiutenza la versione "embedded".

Rettifico, non è uno spreco, non ha semplicemente senso.

Altri formati esclusivamente "file based", come Access, non prevedono interazioni tra un client ed un server, non esiste quindi un protocollo che deve essere rispettato come avviene per FireBird in cui queste entità esistono ma in cui non sono contemplate meccaniche di gestione dei lock, non utilizzabili in ambito client/server e non introducibili per motivi di compatibilità nella versione "embedded" in quanto questa deve essere pienamente sostituibile alla versione client "classica" che accede ad un server, anche locale, al posto di un file fisico direttamente.

Riassumendo, se l'utente vuole un prodotto pronto all'uso e adopera FireBird, in locale può usare la versione "embedded"; non ha senso ed è uno spreco avere funzionalità multiutente nella versione "embedded": se vi è la necessità di lavorare con più utenti, il signor cliente si installa la versione client/server, adoperabile senza apportare modifiche all'applicazione esistente (salvo indicare un percorso logico relativo al server piuttosto che un percorso fisico).


Mi riferivo all'autore originale della discussione.

Chiedere quale database scegliere senza indicare cosa ci deve fare, di fatto, permette a chiunque di scrivere il proprio formato o DBMS preferito senza aggiungere argomentazioni in quanto... non c'è nulla da argomentare: non è chiaro quali sono le specifiche, quindi vanno bene tutti.

Si parla genericamente di "gestionali", ma ne esistono di vario tipo. Ipotizzo qualche scenario: si deve avere anche un accesso via Web o un'interazione con siti e servizi esterni? E' necessario il multipiattaforma?

Se l'autore è ancora interessato a questa discussione, dovrebbe rispondere.

Ciao!

Attenzione però, tu ti stai focalizzando esclusivamente su Firebird e Firebird embedded e le tue argomentazioni in questo ambito sono validissime, sarebeb stato uno spreco fornire Firebird embedded di multiutenza esistendo già Firebird. Io però ho chiesto una cosa diversa, e il secondo scenario che ti ho esemplificato è calzante a questo proposito: ho chiesto se esiste un DBMS multiutente disponibile sottoforma di libreria embeddable in u'applicazione. Non ho fatto alcun riferimento al fatto che tale DBMS debba essere filebased. In particolare se esistesse
libreria del genere in java sarebbe possibile distribuirla nella cartelal lib di una propria applicazione java lato server ed ottenere una gestione dei dati via DBMS "autocontenuta" se mi passi il termine. Spero di essermi chiarito.

[alka]

Originariamente inviato da unomichisiada
ho chiesto se esiste un DBMS multiutente disponibile sottoforma di libreria embeddable in u'applicazione.
Non ho fatto alcun riferimento al fatto che tale DBMS debba essere filebased.[...]

La tua prima affermazione è la definizione di un DBMS "file based", come Access, Paradox, ...

[unomichisiada]

Originariamente inviato da alka
La tua prima affermazione è la definizione di un DBMS "file based", come Access, Paradox, ...

Bene abbiamo appurato due cose:
1) Io non conosco esattamente la definizione di DBMS filebased
2) Io non sto cercando un DBMS filebased ma un'altra cosa che a questo punto non saprei come definire e che probabilmente non è stata realizzata da nessuno. Un'idea per un progetto...

[kuarl]

hsqldb supporta la concorrenza ma non a livelli molto spinti. Complessivamente fa segnare delle ottime prestazioni, ma se ti serve un dbms concorrente ad alte prestazione come dice alka ti serve un database server