Qual è il modo migliore per determinare quando è appropriato utilizzare un database?

Ho iniziato la mia carriera di programmatore nello sviluppo web usando PHP e MySQL. Mi sono abituato a utilizzare db per l'archiviazione della maggior parte dei dati dinamici e di alcuni dati di impostazione / parametro. A volte ci sarebbero molti dati mentre altre volte le voci nelle tabelle sarebbero poche. A me questo è sembrato naturale e per quanto ne so questo è più o meno un approccio accettabile nello sviluppo web. (Per favore correggimi se sbaglio...)

Sto approfondendo le applicazioni desktop ora e la mia naturale inclinazione è quella di utilizzare nuovamente un db per archiviare molte informazioni che verranno generate attraverso l'utilizzo dell'applicazione. Tuttavia, per quanto ne so, non vedo le applicazioni (che uso) che utilizzano un db molto spesso. [EDIT: Da allora è stato sottolineato che si è trattato di un presupposto errato in quanto molte applicazioni utilizzano dbs leggeri incorporati nel programma stesso.] Qual è la ragione di ciò? A che punto è opportuno utilizzare un db? Ci sono degli standard in materia? Inoltre, quali sono i motivi per NON utilizzare un db per sviluppare un'applicazione desktop?

se l'applicazione è orientata ai documenti, archiviare le cose in un file di documento

se l'applicazione si occupa di dati più strutturati, troppo per un singolo documento (come un documento XML), utilizzare un database

Un sistema di database è stato tradizionalmente visto come un servizio relativamente pesante, che non si voleva necessariamente installare su ogni macchina client là fuori. In realtà sono stato in situazioni (sviluppo di app per la GUI desktop in cui un sacco di dati dovevano essere salvati) in cui un vero sistema DB sarebbe stato una soluzione "ideale" - ma poiché in passato gli unici database disponibili erano relativamente pesanti, siamo andati invece con file di dati flat.

Nonostante ci siano alcuni database più leggeri là fuori in questi giorni, questo è ancora un argomento valido contro i database lato client. Immagina qualche semplice piccola app desktop (come ad esempio un semplice giocattolo o gioco desktop) che deve memorizzare alcune dozzine di impostazioni e parametri. Sembra davvero esagerato far installare MySQL solo per eseguire la tua app.

Con lo sviluppo web, il server è naturalmente un back-end, dove avere un database è alla base. per esempio. Gli utenti non devono preoccuparsi di installare un database alla fine.

Le applicazioni desktop mantengono lo stato mentre sono in esecuzione. Considerando che lo sviluppo web in genere non lo fa. Pertanto, mentre potrebbe essere necessario archiviare un'impostazione utente in un database tra i carichi di pagina, in un'app desktop è sufficiente tenerli in memoria. Ciò riduce notevolmente la necessità di tali tipi di archiviazione persistente. Quando si desidera memorizzare le preferenze tra gli usi, è possibile salvarle tutte in un unico file o inserirle in un posto come il registro di Windows.

Detto questo, i sistemi di database sono molto usati nelle app desktop. Molto prima del web, le applicazioni desktop sono state connesse ai DBMS. Principalmente per applicazioni che non sono basate su documenti. Anche se in questi giorni, con la migliore disponibilità di motori leggeri, stai vedendo le linee un po 'sfocate. Ad esempio, utilizzo i DB di SQLite come documenti in alcune delle mie app.

Una cosa che potresti voler esaminare sono i database leggeri che non richiedono un vero servizio di database in esecuzione. ad es. sul fronte Microsoft c'è SQL Server Compact , che è gratuito, richiede solo un singolo file per il database e alcune DLL aggiunte alla tua app, e dal punto di vista di uno sviluppatore, si comporta più o meno allo stesso modo di un "vero" SQL Server.

Sono sicuro che ci sono opzioni simili su altre piattaforme.

Nelle applicazioni Web, è importante archiviare qualsiasi stato persistente su una memoria centralizzata. Poiché l'app Web di solito è il primo collo di bottiglia, è importante essere in grado di distribuirla senza dover mettere in discussione quale copia contiene i dati (il principio "Shared Nothing"). Non solo un database, ma memcachedi sistemi di coda sono lì per lo stesso motivo.

Le app desktop non hanno lo stesso obiettivo di scalabilità. In genere, la maggior parte dei dati viene archiviata localmente su ciascuna workstation. La condivisione dei dati è un problema diverso nella maggior parte dei casi. Ciò elimina un grande motivo per utilizzare un database.

Le applicazioni della GUI possono anche avere documenti complessi che potrebbero essere gestiti come una complessa rete di oggetti in memoria. La normalizzazione della struttura in uno schema DB relazionale può aggiungere una notevole complessità al problema, a volte è più semplice serializzare il tutto in un singolo test. Molti framework OOP includono alcune strutture proprio per questo.

Tuttavia, rendere i documenti archiviati leggibili con strumenti esterni all'applicazione principale è un grande vantaggio in molti casi, quindi sia l'utilizzo di formati leggibili dall'uomo (XML, JSON, YAML, ecc.), Sia un file zip che unisce diversi pezzi più semplici stanno ottenendo di più e più comune.

Allo stesso modo, l'utilizzo di una libreria di database incorporabile (BDB, Tokyo Cabinet, SQLite, MS-SQL * server Compact, ecc.) È un altro ottimo approccio.

I database possono essere eccessivi ma di solito non devono esserlo. Programmi molto semplici non ne hanno bisogno. Se il tuo documento può caricarsi in memoria in un tempo insignificante e rimanere lì senza problemi, non hai davvero bisogno di uno per molti programmi.

Ad esempio, considera:

#include "superheader.h"

int main()
{
    int row=2, column=2;
    DatabaseType db;
    db.ConnectTo("programDB", "user", "pass");
    db.setTable("messages");
    string hello_world=db.fetch(row, column);
    cout<<hello_world;
    return 0;
}

Bene, questo è eccessivamente semplicistico, ma ovviamente è troppo. Non ha senso avere quel livello di gestione dei dati per "Hello World"

Di solito la regola empirica che seguo è l'uso di un database se si dispone di molti insiemi di dati, soprattutto se sono unicamente diversi o utilizzare un database se la quantità di dati è piuttosto massiccia. I database in generale sono associati ad un certo sovraccarico, ma ce ne sono molti che in realtà non hanno molto. Database di piccole dimensioni, leggeri e in memoria, ad esempio, sono talvolta utili per piccoli progetti con elaborazione, pianificazione o molte modifiche dinamiche ai dati.

Esistono diversi stili di codifica, molte volte non c'è niente di sbagliato in un database ma la maggior parte di noi non andrà "così lontano" per le attività di base. Ci sono ancora altre volte che il database giusto offrirebbe vantaggi in termini di prestazioni. Cerca di comprendere in particolare le differenze su dove saranno i dati, quanto tempo rimarranno lì e cosa li cambierà durante la loro durata.

Usare un db è sempre la cosa giusta e con le implementazioni di SQLite praticamente per ogni lingua là fuori non usarne una è solo un cattivo processo decisionale. L'unico motivo per non usarne uno è se stai eseguendo una programmazione integrata o qualche altro tipo di programmazione non applicativa. L'interrogazione di dati e impostazioni con un linguaggio dichiarativo come SQL è molto più naturale del passaggio di file flat o altri oggetti in memoria con sintassi imperativa. Inoltre, separa in modo pulito le operazioni sui dati da altri codici applicativi che a lungo andare rendono il codice più modulare e gestibile.