Come decidere tra i formati di archiviazione e quali sono i casi d'uso di esempio per alcuni di essi?


10

Esistono diversi modi per memorizzare i dati del programma (salvare i file in giochi, database dei dipendenti, configurazione del programma ecc.):

  • Testo semplice (pensa .inie .conf)
  • XML
  • Database (MySQL, SQLite ...)
  • .zip e simili contenenti diversi file (con diversi formati)
  • File binari (pensa .docecc., Ad esempio creati da uno strumento di serializzazione)

Quali sono i diversi casi d'uso per i formati sopra elencati e quali sono i loro vantaggi contro svantaggi (si pensi a velocità, flessibilità, dimensione del file, facilità d'uso ...)? Come decidere tra loro per compiti diversi?

Informazioni sul formato zippato: è usato solo per contenere altri file. Potrebbe essere anche un altro formato di compressione. Ciò consente una struttura di più file, inclusi file di immagine, file audio e file di testo. Ad esempio, supponiamo di avere un formato di archiviazione per i messaggi, che può contenere file. Puoi avere i seguenti file all'interno di un file zippato:

message.txt (containing the message)
attachments (folder containing attachments)
  audio.wav
  picture.jpg

wrt binary, considera Google Protocol Buffer. La pigra capacità di deserializzazione è fantastica e hai sempre la possibilità di estrarla e salvarla come testo formattato (in diverse lingue C ++ / Java / Python).
Matthieu M.

Risposte:


6

Io uso come segue:

Testo semplice

Per la configurazione, di solito utilizzando YAML o .ini. Da me deprecato per la maggior parte degli usi tranne quando un file di testo è il risultato desiderato (ad es. Stampa su testo, salvataggio su testo ecc.)

XML

Per la configurazione e il trasporto di dati; es. esportazione, formattazione tramite XSLT ecc. Buono come formato di file portatile (es. SVG). Strumenti e filtri di manipolazione eccellenti.

Banche dati

Memoria principale dei dati dall'app / webapp interna. Usalo sempre come memoria di scelta. È affidabile, robusto e molto integrato (transazioni, integrità referenziale, cancellazione / aggiornamento a cascata, indici, velocità). Utilizzato al meglio con un livello o ORM (IMO).

Archivio file singolo (es. .Zip)

Adatto per memorizzare in modo compatto più flussi binari correlati, ad esempio immagini ROM per un emulatore. Ideale per cose che spesso non devono essere aggiornate o mai aggiornate. È pesante, lento e difficile da manipolare;

Binario

Solo dove non è disponibile un database per l'archiviazione dei dati delle app. Più semplice con la serializzazione (C ++). Un formato binario altamente ottimizzato supererà qualsiasi altra cosa per velocità e dimensioni.


4

Non c'è proiettile d'argento. Nella mia esperienza:

Il testo in chiaro come supporto di memorizzazione è un no automatico. I pochi casi che prenderei anche in considerazione sarebbero meglio coperti da un file .config in cui ho uno schema e un tipo di sicurezza. Sembra che la necessità della sicurezza dei tipi e dell'estrazione dei dati emergano quasi sempre. Il semplice testo rende questo processo un incubo.

XML : digitare sicurezza, convalida dei dati, volume basso e in alcuni casi lo uso perché .NET ha un potente supporto integrato per la serializzazione XML degli oggetti.

Database : il mio valore predefinito. Digitare sicurezza, velocità, transazioni, ben attendibile e difficile da incolpare per aver scelto un DB come supporto di archiviazione se qualcosa non va secondo i piani.

.zip è un formato di compressione, non sei sicuro di come si adatta alla persistenza ..?

Binario : utilizzo il binario solo quando devo creare un memorystream temporaneo. Il binario non aggiunge valore in termini di capacità di query rispetto a un DB o XML in cui i miei dati sono organizzati con schema.

La facilità d'uso è relativa e dipende da ciò che si desidera realizzare. La velocità è simile al di fuori di quello che ho detto sopra riguardo al volume. Se la dimensione del file è un problema e viene applicata una normale normalizzazione, lo comprimerò tramite zip o un altro formato di compressione, ma questo è un processo separato.


3

Li uso come segue:

Testo semplice

Se quella categoria include formati leggermente più elaborati, come YAML o file delle proprietà, allora è l'opzione migliore per qualunque cosa ti aspetti che le persone leggano e modifichino manualmente. Un altro enorme vantaggio è la semplicità di modificarlo tramite un piccolo script (ad esempio 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 client) o l'IT deve riconfigurare un gruppo di server che eseguono il software, ti ringrazieranno per aver scelto questo formato. Ti salverà anche dalla scrittura di un software unico che lo fa per loro.

XML

Sono d'accordo con @Ingo qui - a differenza del semplice testo XML è più difficile da elaborare tramite script e un incubo da modificare a mano imo.

Tuttavia, se si dispone di dati con una struttura elaborata in cui YAML diventa indecifrabile e si desidera comunque che sia leggibile e modificabile dall'uomo, l'XML è probabilmente la scelta migliore.

Database relazionale

Un'ottima scelta per quando hai molti dati (che renderebbero ingombranti il ​​testo semplice e XML) che potresti comunque voler consentire a terze parti di modificare manualmente - tramite comandi SQL e persino GUI.

Un altro vantaggio è che il tuo codice che gestisce i contenuti è molto leggibile. @ Richard-Harrison ha dato un buon elenco di altri vantaggi nella sua eccellente risposta.

Database NoSQL

Un vantaggio rispetto a RDBMS è la scalabilità attraverso la distribuzione, che probabilmente non è molto rilevante per la tua domanda. I vantaggi che sono probabilmente più rilevanti sono la semplicità di un archivio di valori-chiave e la flessibilità dello schema elettrico (è una parola?). Quando ti trovi a rompere il paradigma relazionale: basta archiviare i BLOB nel database, accedervi tramite chiave ed elaborarli tramite il codice, quindi prendere in considerazione questa opzione. Alcune scelte (ad es. CouchDB) sono molto portatili, hanno un ingombro ridotto e possono anche ridimensionarsi in modo da offrire una buona alternativa non relazionale a MySQL e SQLite.

Binario

Il vantaggio del binario è che è veloce e compatto. Quando l'unica cosa che deve leggere e modificare il tuo file è un programma e i dati non si adattano al paradigma relazionale o alla velocità è davvero importante, questa potrebbe essere una buona scelta. Probabilmente la soluzione migliore per i file multimediali.

Devo sottolineare tuttavia che non ho ancora riscontrato un caso in cui un semplice accesso ai dati del programma non è richiesto ad un certo punto per motivi che non sono stati considerati durante la progettazione iniziale. Oggi scelgo personalmente l'opzione di database per qualsiasi cosa diversa dai file che hanno formati standard e devono essere codificati / decodificati da altri software (ad esempio audio, video).

Nota: c'è un malinteso comune sul fatto che il binario sia opaco e quindi in qualche modo più sicuro. Senza protezione aggiuntiva non lo è - se qualcuno vuole hackerare il tuo software, semplicemente archiviare le tue configurazioni o qualsiasi cosa in binario non le fermerà.

Archivio compresso

Non è davvero un'alternativa a quanto sopra, ma piuttosto una misura in più.

Vantaggioso quando è necessario trasmettere cose sulla rete o quando si memorizzano molti dati e si desidera risparmiare spazio. Tieni presente che lo spazio di archiviazione è di solito abbondante in questi giorni, quindi considera la tua piattaforma di destinazione.

Si esibisce molto velocemente su quasi tutto oggi (legge di Moore in azione, piccola), quindi l'unica ragione per non usarlo è che aggiunge complessità al tuo codice. Non molta complessità, ma comunque una violazione del principio KISS. Soprattutto ingombrante per i file di configurazione che devono essere modificati manualmente o tramite script - e se hai davvero bisogno di risparmiare spazio lì, probabilmente dovresti usare l'opzione del database.


2

Li userei come segue:

  • Testo semplice : l'applicazione ha dimensioni ridotte di dati semplicemente strutturati (coppie nome valore per es.). I dati non vengono modificati contemporaneamente da più utenti.
  • XML : dimensioni ridotte di dati strutturati che non vengono modificati contemporaneamente o frequentemente.
  • Database : sono necessari grandi dati strutturati o accesso simultaneo. È necessario eseguire query e ricerche nell'applicazione.
  • Dati binari : lo userei solo per gli oggetti in streaming.
  • zippare è la compressione che può essere aggiunta come un altro processo per uno qualsiasi dei precedenti, ad eccezione dei database sui server.

1

Ho sentito che XML combina le peggiori funzionalità del testo (difficile / lento da elaborare) e binario (illeggibile).


Non una risposta completa
Anto,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.