Quali sono le diverse considerazioni da fare nel determinare il formato dei dati persistenti? [duplicare]

4

Recentemente ho avuto difficoltà con il concetto di quale struttura di file utilizzare quando si creano i file di salvataggio per le applicazioni desktop. Quando dico "salva-file" intendo qualcosa come i file * .doc. File che contengono il lavoro che l'utente inserisce nel programma e vogliono poter caricare e riprendere il proprio lavoro in un secondo momento.

Cose come la serializzazione binaria sono facili, anche se se e quando il modello per le applicazioni viene ri-fattorizzato o espanso, ciò interrompe (credo) i file salvati con il formato precedente. Cose come XML e JSON sono più resistenti ai cambiamenti futuri, ma mi sento come se stessi cadendo nella trappola dell'uso XML come il mio "martello d'oro" per così dire. Un database sembra eccessivo per praticamente tutte le applicazioni che sviluppo.

Quali sono alcune opzioni comuni, e sono sicuro che ce ne siano molte, che non sto considerando? Puoi descrivere quando ciascuna di queste opzioni è meglio utilizzata e perché è la scelta migliore?

    
posta Anthony 25.07.2011 - 15:30
fonte

2 risposte

4

I file binari non devono rompersi. Potresti avere lettori di file per diverse versioni del file, o provare a fare versioni future aggiungi al modello di dati esistente piuttosto che modificarlo. In questo modo i vecchi file possono probabilmente ancora essere letti. Probabilmente vorrai anche che il file tenga un "numero di versione" in modo che il lettore di file sappia quale versione del modello di dati con cui sta lavorando (la supposizione può andare terribilmente male). Non so che tipo di dati sia, ma potresti anche usare un semplice file di testo strucutred, o qualcosa come YAML .

In generale, alcune considerazioni (ce ne sono molte altre che probabilmente non riesco a pensare in questo momento) sono:

  • Quanto sono complessi i dati? Alcuni formati di dati, come la geometria 3D, possono essere facilmente archiviati in file di testo molto semplici.

  • Programmi diversi dal tuo lo utilizzeranno? Questo potrebbe essere un buon motivo per utilizzare XML e inviare ad altri programmi client un file di schema in modo che possano leggere molto facilmente lo schema e i file di dati.

  • Il modello di dati cambierà probabilmente in futuro? Questo può essere difficile da gestire se non è possibile avere una chiara idea dei cambiamenti futuri. Anche in questo caso, XML potrebbe mitigare questo, ma tu dici di voler evitare la sindrome "XML Golden Hammer", e se il formato del file è molto semplice, un numero di versione sulla prima riga potrebbe essere abbastanza buono per un testo o un formato binario del file.

  • Quanto è grande il file di dati? Se il file è molto grande, è possibile comprimere l'output risultante che riduce l'utilizzo del disco che aumenterà il tempo di caricamento. Quanto è importante per l'utente finale?

risposta data 25.07.2011 - 15:49
fonte
1

Hai considerato i database integrati leggeri per il tuo formato di file, in particolare SQLite o ESENT?

SQLite come formato di file.

  • transazionale
  • Query SQL
  • ORM friendly

O forse ESENT (solo per Windows)

  • prestazioni elevate
  • archiviazione basata su tabella
  • transazionale
  • già disponibile su tutto il moderno versioni di Windows; nessun problema di distribuzione.
  • librerie per .NET e C ++
risposta data 25.07.2011 - 17:21
fonte

Leggi altre domande sui tag