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

se la tua applicazione è orientata ai documenti, archivia 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), usa un database

Un sistema di database è stato tradizionalmente visto come un servizio relativamente pesante, che non si voleva necessariamente installare su ogni macchina client. In realtà sono stato in situazioni (sviluppo di app per desktop GUI in cui era necessario salvare molti dati) in cui un vero sistema DB sarebbe stato una soluzione "ideale", ma perché nel passato gli unici database disponibili erano relativamente pesanti, abbiamo usato invece file di dati flat.

Nonostante esistano alcuni database più leggeri là fuori in questi giorni, questo è ancora un argomento valido contro i database lato client. Immagina alcune semplici app per desktop (come ad esempio un semplice gioco o gioco desktop) che deve memorizzare alcune decine di impostazioni e parametri. Sembra davvero il modo migliore per far installare una persona MySQL solo per eseguire la tua app.

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

Le applicazioni desktop mantengono lo stato mentre sono in esecuzione. Mentre lo sviluppo web in genere non lo fa. Pertanto, anche se potrebbe essere necessario memorizzare le impostazioni di un utente in un database tra un carico di una pagina, in un'applicazione desktop è sufficiente mantenerle in memoria. Ciò riduce notevolmente la necessità di tali tipi di archiviazione persistente. Quando vuoi memorizzare le preferenze tra usi, puoi salvarli tutti in un file, o metterli in un posto come il registro di Windows.

Detto questo, i sistemi di database sono usati parecchio nelle app desktop. Molto prima del web, le applicazioni desktop sono state collegate ai DBMS. Principalmente per applicazioni che non sono basate su documenti. Anche se in questi giorni, con la migliore disponibilità di motori leggeri, stai vagliando un po 'le linee. Ad esempio, utilizzo i documenti come di SQLite db 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. per esempio. sul fronte Microsoft c'è SQL Server Compact , che è gratuito, richiede solo un singolo il file per il database e alcune DLL aggiunte alla tua app e dal punto di vista dello sviluppatore si comportano allo stesso modo di un "vero" SQL Server.

Sono positivo che ci siano opzioni simili su altre piattaforme.

Sulle applicazioni web, è importante memorizzare qualsiasi stato persistente su una memoria centralizzata. Dato che l'app Web di solito è il primo collo di bottiglia, è importante essere in grado di distribuirla senza dover mettere in discussione la copia dei dati (il principio "Shared Nothing"). Non solo un database, ma memcached e sistemi di code ci sono per lo stesso motivo.

Le app desktop non hanno lo stesso obiettivo di scalabilità. In genere, la maggior parte dei dati viene memorizzata localmente su ogni workstation. La condivisione dei dati è un problema diverso nella maggior parte dei casi. Questo elimina una grande ragione per usare un database.

Le applicazioni 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 di DB relazionale può aggiungere una notevole complessità al problema, a volte è più semplice serializzare l'intera operazione in un singolo attimo. Molti framework OOP includono alcune funzionalità solo per questo.

Tuttavia, rendere i documenti archiviati leggibili con strumenti esterni all'applicazione principale è un grande vantaggio in molti casi, quindi o utilizzando formati leggibili dall'uomo (XML, JSON, YAML, ecc.) o un file zip che amalgama diversi pezzi più semplici sono diventando sempre più comune.

Sulla stessa falsariga, l'uso di una libreria di database integrabile (BDB, Tokyo Cabinet, SQLite, MS-SQL * server Compact, ecc.) è un altro ottimo approccio.

I database possono essere overkill ma in genere non hanno . I programmi molto semplici non ne hanno bisogno. Se il tuo documento può essere caricato in memoria in una quantità insignificante di tempo 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;
}

Questo è troppo semplicistico, ma ovviamente è troppo. Non c'è alcun vero punto di avere quel livello di gestione dei dati per "Hello World"

Di solito la regola generale che passo è usare un database se hai molti set di dati, specialmente se sono univocamente diversi OPPURE usi un database se l'importo dei dati è piuttosto massiccio. I database in generale sono associati a qualche overhead, ma ce ne sono molti che in realtà non hanno molto. I database piccoli, leggeri e in-memory, ad esempio, sono a volte utili per piccoli progetti con pesanti elaborazioni, pianificazioni o molte modifiche dinamiche ai dati.

Ci sono diversi stili di codifica, molte volte non c'è niente di sbagliato in un database, ma la maggior parte di noi semplicemente non andrà "così lontano" per le attività di base. Ci sono ancora altre volte che il database giusto offre vantaggi in termini di prestazioni. Cerca di capire in particolare le differenze in cui i dati saranno, quanto tempo ci sarà e cosa cambierà durante la sua vita.

L'uso di un db è sempre la cosa giusta e con le implementazioni SQLite praticamente per ogni lingua là fuori non usarne uno è solo un pessimo processo decisionale di progettazione. L'unica ragione per non usarne una è se stai facendo programmazione embedded o qualche altro tipo di programmazione non di applicazione. Interrogare dati e impostazioni con un linguaggio dichiarativo come SQL è molto più naturale che attraversare file flat o altri oggetti in memoria con una sintassi imperativa. Inoltre, separa in modo pulito le operazioni dei dati da un altro codice dell'applicazione che a lungo termine rende il codice più modulare e gestibile.