Li uso come segue:
Testo normale
Se quella categoria include formati leggermente più elaborati, come YAML o file di proprietà, allora è l'opzione migliore per qualsiasi cosa tu pensi che le persone possano leggere e modificare a mano. Un altro enorme vantaggio è la semplicità di modificarlo tramite un piccolo script (ad es. Sed).
Niente batte la semplicità e la facilità d'uso. Quando il team di supporto deve configurare qualcosa su una macchina remota (ad esempio, risolvere il problema di un cliente) o l'IT deve riconfigurare un gruppo di server che eseguono il software, ti ringrazieranno per aver scelto questo formato. Ti farà risparmiare anche la scrittura di alcuni software unici che lo fanno per loro.
XML
Sono d'accordo con @Ingo qui - a differenza del testo semplice XML è più difficile da elaborare tramite script e un incubo da modificare a mano imo.
Tuttavia, se disponi di dati con una struttura elaborata in cui YAML diventa indecifrabile e desideri comunque che sia leggibile e modificabile dall'uomo, allora XML è probabilmente la scelta migliore.
Database relazionale
Un'ottima scelta per quando hai molti dati (che renderebbero il testo normale e l'XML ingombrante) che potresti comunque voler consentire a terze parti di modificare manualmente, tramite comandi SQL e persino GUI.
Un altro vantaggio è che il codice che gestisce i contenuti è molto leggibile. @ Richard-Harrison ha fornito una buona lista di altri vantaggi nella sua eccellente risposta.
Database NoSQL
Un vantaggio rispetto a RDBMS è la scalabilità attraverso la distribuzione, che probabilmente non è molto pertinente alla tua domanda. I vantaggi che sono probabilmente più rilevanti sono la semplicità di un negozio di valore-chiave e la flessibilità di schemalessness (è questa una parola?). Quando ti trovi a rompere il paradigma relazionale: semplicemente memorizzando i BLOB nel database, accedendoli per chiave e processandoli attraverso il codice, considera questa opzione. Alcune scelte (ad esempio CouchDB) sono molto portabili, hanno un ingombro ridotto e possono essere ridimensionate in modo da offrire una valida alternativa non relazionale a MySQL e SQLite.
Binary
Il vantaggio del binario è che è veloce e compatto. Quando l'unica cosa che ha bisogno di leggere e modificare il tuo file è un programma ei dati non si adattano al paradigma relazionale o la velocità è davvero importante, questa potrebbe essere una buona scelta. Probabilmente la soluzione migliore per i file multimediali.
Devo dire che non ho ancora incontrato un caso in cui non è richiesto un accesso semplice ai dati del programma per motivi che non sono stati considerati durante la progettazione iniziale. Oggigiorno scelgo personalmente l'opzione database per qualsiasi cosa diversa dai file che hanno formati standard e devono essere codificati / decodificati da altri software (ad esempio audio, video).
Nota: esiste un malinteso comune sul fatto che il binario sia opaco e quindi in qualche modo più sicuro. Senza una protezione aggiuntiva, non è così: se qualcuno vuole hackerare il tuo software, semplicemente memorizzando le tue configurazioni o qualsiasi altra cosa in binario non le fermerà.
Archivio compresso
Non proprio un'alternativa a quanto sopra, ma piuttosto una misura in più.
Vantaggioso quando è necessario trasmettere cose attraverso la rete o quando si archiviano molti e molti dati e si vuole risparmiare spazio. Nota che lo spazio di archiviazione di solito è abbondante in questi giorni, quindi considera la tua piattaforma di destinazione.
Esegue molto velocemente quasi tutto oggi (legge di Moore in azione, baby), quindi l'unica ragione per non usarlo è che aggiunge complessità al tuo codice. Non molta complessità, ma ancora una violazione del principio KISS. Particolarmente complicato per i file di configurazione che devono essere modificati manualmente o tramite script - e se hai davvero bisogno di risparmiare spazio, allora dovresti probabilmente usare l'opzione database.