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!