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

10

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

  • Testo normale (pensa a .ini e .conf )
  • XML
  • Database (MySQL, SQLite ...)
  • .zip e simili contenenti diversi file (con diversi formati)
  • File binari (pensa .doc ecc., ad esempio creato 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 (pensate a velocità, flessibilità, dimensioni del file, facilità d'uso ...)? Come decidere tra di loro per compiti diversi?

Informazioni sul formato zip: Questo è usato solo per contenere altri file. Potrebbe anche essere un altro formato di compressione. Ciò consente una struttura di diversi file, inclusi file di immagine, file audio e file di testo. Ad esempio, supponiamo di avere un formato di archiviazione per i messaggi, che potrebbe contenere file. Puoi avere i seguenti file in un file zippato:

message.txt (containing the message)
attachments (folder containing attachments)
  audio.wav
  picture.jpg
    
posta Anto 16.04.2011 - 15:04
fonte

5 risposte

5

Uso come segue:

Testo normale

Per la configurazione, in genere utilizzando YAML o .ini. Deprecato da me per la maggior parte degli usi tranne quando un file di testo è il risultato desiderato (ad esempio, stampa su testo, salva in testo ecc.)

XML

Per la configurazione e il trasporto dei dati; per esempio. esporta, formatta tramite XSLT ecc. Buono come un formato di file portatile (ad esempio SVG). Strumenti e filtri di manipolazione eccellenti.

Database

Memoria dati principale dall'interno dell'app / webapp. Usalo tutto il tempo come deposito di scelta. È affidabile, robusto e molto integrato (transazioni, integrità referenziale, eliminazione / aggiornamento a cascata, indici, velocità). Ideale per un livello o ORM (IMO).

Archivio file singolo (ad esempio .zip)

Adatto per memorizzare in modo compatto stream binari correlati, ad es. Immagini ROM per un emulatore. Ideale per le cose che non sono spesso o non devono essere aggiornate. È pesante, lento e difficile da manipolare;

Binary

Solo dove un database non è disponibile per la memorizzazione dei dati dell'app. Più semplice con la serializzazione (C ++). Un formato binario altamente sintonizzato supererà tutto il resto per velocità e dimensioni.

    
risposta data 16.04.2011 - 16:24
fonte
3

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

Testo normale come supporto di archiviazione è un numero automatico. I pochi casi che considererei potrebbero essere coperti da un file .config in cui ho uno schema e un tipo di sicurezza. Sembra che la necessità di sicurezza del tipo e di estrazione dei dati si presenti quasi sempre. Il testo semplice rende questo processo un incubo.

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

Database : il mio valore predefinito. Digitare sicurezza, velocità, transazioni, affidabile e difficile da ottenere la colpa per il prelievo di un DB come supporto di memorizzazione se qualcosa non va secondo i piani.

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

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

La facilità d'uso è relativa e dipende da ciò che specificamente vuoi ottenere. La velocità è simile al di fuori di quanto ho detto sopra riguardo al volume. Se la dimensione del file è un problema e si applica la corretta normalizzazione, la comprimerò via zip o con un altro formato di compressione, ma questo è un processo separato.

    
risposta data 16.04.2011 - 15:19
fonte
3

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.

    
risposta data 16.04.2011 - 19:12
fonte
2

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

    
risposta data 16.04.2011 - 15:14
fonte
2

Li userei come segue:

  • Testo normale : l'applicazione ha dimensioni ridotte di dati semplicemente strutturati (coppie di valori nome per esempio). I dati non vengono modificati contemporaneamente da più utenti.
  • XML : dimensioni ridotte dei dati strutturati che non vengono modificati contemporaneamente o frequentemente.
  • Database : sono necessari dati strutturati di grandi dimensioni o accesso simultaneo. La necessità di eseguire query e la ricerca è un must nell'applicazione.
  • Dati binari : lo utilizzerei solo per lo streaming di oggetti.
  • zipping è la compressione che può essere aggiunta come un altro processo per uno dei suddetti eccetto i database sui server.
risposta data 16.04.2011 - 15:31
fonte

Leggi altre domande sui tag