L'utilizzo di un server di database ha senso se l'applicazione esegue le cose solo localmente?

SQLite offre un riepilogo di quando usarlo o meno rispetto alle alternative:

link

Questa linea di riepilogo cattura molto bene il caso d'uso di SQLite nella mia esperienza:

SQLite does not compete with client/server databases. SQLite competes with fopen().

L'articolo si espande a lungo su questo punto. Ha anche una sezione intitolata "Situazioni in cui un client / server RDBMS può funzionare meglio". In poche parole, sono:

• Applicazioni client / server : più utenti su una rete.
• Siti web ad alto volume : è necessario scrivere in modo intensivo o leggere con sufficiente intensità per richiedere la condivisione.
• Set di dati molto grandi : più grandi di quelli che possono essere ragionevolmente memorizzati su un disco.
• Concorrenza elevata : in particolare le scritture concorrenti.

Anche per un singolo sistema con un singolo utente, un server di database "reale" ha senso:

1. Utilizza un linguaggio familiare ( SQL ). SQLite utilizza SQL, ma alcuni database incorporati (ad esempio oggetto database , NoSQL ) non utilizzare SQL. Quelli tendono ad avere una curva di apprendimento più alta perché sono meno comuni.
2. Fornisce integrità referenziale, vincoli, trigger ecc. che prodotti come SQLite potrebbero non fornire o almeno fornire non completamente.
3. Puntando a un vero e proprio database multiutente, ACID , l'applicazione ha la possibilità di lavorare in un unico scenario utente / workstation singola o come applicazione host multiutente utilizzando la stessa base di codice .
4. L'utente ha la possibilità di esaminare i dati offline utilizzando strumenti standard (ad es. SQL Developer, MySQL Workbench, SQL Server Management Studio), caricare o eseguire il backup dei dati utilizzando tali strumenti, ecc. Mentre è possibile farlo con molti embedded database di vario tipo, le persone forse hanno più familiarità con quegli strumenti dal mondo dei database C / S.

Lo svantaggio principale è la necessità di installare e gestire il software del server del database, che è un po 'complesso per gli utenti non tecnici (e anche per molti utenti tecnici). I sistemi operativi come Linux lo rendono più semplice: ho PostgreSQL e MySQL in esecuzione sul mio sistema Linux. Ho installato applicazioni che si sono agganciate a loro con poca o nessuna interazione da parte mia.

Penso che abbia a che fare con l'inerzia.

Amarok è basato su XMMS che risale al 1997. Per avere le capacità del database good dovevi usare un server, perché era molto più potente delle soluzioni basate su file, che da no significa ha buone capacità di database.

L'imminente e crescente popolarità dei buoni database locali incorporati come SQLlite è qualcosa di abbastanza recente.

La caratteristica discriminante più importante è concorrenza .

Se si dispone di una sola applicazione che viene eseguita in un'unica istanza per l'utente, la soluzione incorporata (che sia di tipo sqlite o di alcuni oggetti) di solito è OK.

Tuttavia, se si dispone di più istanze che devono manipolare il database contemporaneamente, è necessario disporre di un server per sincronizzarlo. SQLite consente solo una scrittura alla volta, nell'intero database e così fa la maggior parte delle altre soluzioni incorporate. E se hai persino più applicazioni, è probabile che tu abbia bisogno di specifiche di vincoli più dettagliate che le soluzioni integrate generalmente non consentono neanche.

Molte altre risposte parlano della concorrenza come un vantaggio, ma anche dal momento che il db è in esecuzione come server, il database può eseguire attività senza che l'applicazione sia in esecuzione. Potrebbe trattarsi di manutenzione, backup, sincronizzazione con un altro server o attività pianificate.

Se ritieni che la tua app possa trasformarsi in un'app client / server, potresti iniziare a utilizzare un RDBMS dall'inizio invece che a portarlo più tardi.

Non ho idea se l'esempio fornito ne tragga vantaggio o meno.

A meno che tu non stia utilizzando un sistema embedded con memoria insufficiente e CPU, non penso che l'esecuzione di un server sullo sfondo ti faccia del male.

L'esecuzione locale di un server di database va bene. Il database ha lo scopo di accedere e manipolare i dati. L'accesso alla rete è un vantaggio, che può essere o non essere necessario. Ci sono alcuni strumenti ingegneristici e scientifici che fanno questo.

Supponiamo che tu stia utilizzando i dati, su un'applicazione locale. Perché non dovresti usare un database? al contrario di cosa?

Dipende dall'astrazione dei dati e dallo spazio complessivo dell'applicazione, dai requisiti di gestione degli accessi, dall'investimento che si sta pianificando per la manutenzione dei dati, dall'urgenza del prototipo richiesto, dalla curva di apprendimento, ecc.

Se si desidera assicurare un database strettamente integrato a un'applicazione che non richiede l'accesso da altre applicazioni, creando isole di database incorporati. Come esempio, l'implementazione di Mozilla Firefox Web Storage con SQLite.

Se hai bisogno di un'efficienza ancora maggiore con dati limitati, è preferibile una selezione di design dei database In-Memory.

D'altro canto, se molte applicazioni eseguono più query sugli stessi dati e richiede una migliore strutturazione della memorizzazione dei dati per ottimizzare le prestazioni, è necessario un DBMS centralizzato. Lo preferirò assolutamente per la ricerca scientifica, quando richiede una quantità enorme di dati e in cui il tempo di risposta alle query influirà drasticamente sull'esperienza utente complessiva.

Per il caso Amarok, suppongo che fosse una selezione di DBMS open-source in quel momento, prima che scegliessero il percorso dei database incorporati.

Se esiste una definizione di sistema specifica a portata di mano, sarà più facile pesare contro e pro.

V / r, Umut