Meilleures pratiques pour les structures de fichiers personnalisées

Question

Je suis actuellement assez curieux de voir comment les autres programmeurs organisent les données dans des fichiers. Quelqu'un peut-il recommander de bons articles ou de bons livres sur les meilleures pratiques pour créer des structures de fichiers?

Par exemple, si vous avez créé votre propre logiciel à quelque fin que ce soit, laissez-vous les données sauvegardées sous forme de texte brut, sérialisez-vous-les, encodez-vous en XML, et pourquoi le faites-vous?

Y a-t-il des secrets que j'ai manqués?

Answer 1

En règle générale, choisissez la méthode la plus simple qui puisse fonctionner, du moins au début. Par exemple, sous UNIX, où la plupart des fichiers de configuration ne sont que des champs délimités par des espaces, ou des champs délimités par un autre caractère (comme / etc / passwd, qui utilise les délimiteurs ":", car le champ GCOS peut contenir des blancs.)

Si vos données nécessitent beaucoup plus de structure, demandez-vous quels outils puis-je utiliser facilement? " Python et Ruby ont JSON et YAML, par exemple.

XML est utile si vous avez déjà beaucoup de choses basées sur XML, OU si vous prévoyez de transformer le XML en un formulaire affichable dans un navigateur. Sinon, il est généralement très lourd (taille du code, complexité) de ce que vous obtenez.

Answer 2

Peu importe le format que vous choisissez, n'oubliez pas de stocker une sorte de numéro de version à l'intérieur (je suis sûr que vous devrez introduire des modifications).

Le format dépend fortement de l’application et de la quantité de données. Pour certaines applications, XML est approprié, pour d'autres applications, les structures de taille fixe stockées dans un fichier binaire sont correctes.

J'utilise différents formats, en fonction de la situation, par exemple:

• fichier texte brut (délimité) permettant de stocker des jeux de données pour l'analyse Matlab et R
• fichiers binaires - pour stocker des structures de taille fixe (avec une taille dynamique, l'accès aléatoire devient difficile sans maintenir un tableau séparé de décalages pour les éléments). L’un des aspects positifs est l’efficacité et l’efficacité des espaces (pourquoi la plupart des bases de données stockent-elles les données au format binaire?), Mais il n’est pas très utile pour les êtres humains de travailler. Rappelez-vous de l'endianesse.
• XML - généralement pour les données de configuration ou les données que je souhaite transmettre aux applications des autres utilisateurs (avec XSD). L’autre côté peut écrire une belle transformation XSLT ou utiliser les données d’une autre manière (bien sûr, elles pourraient faire la même chose avec du texte brut ou des données binaires en fonction de la description du format)

Answer 3

Sauf si vous avez des exigences uniques, utilisez quelque chose pour lequel il existe déjà une bibliothèque mature, afin d'éviter d'écrire votre propre code d'analyse. Cela signifie XML / JSON, etc., comme l’ont dit les gens.

Les tampons de protocole de Google ( http://code.google.com/p/ sont un bon exemple. protobuf ). Là vous écrivez une définition de message commune et le compilateur de tampon de protocole génère des objets pour compléter, sérialiser et désérialiser les données pour vous. Généralement, le format est binaire, mais vous pouvez également utiliser leur classe TextFormat pour écrire du texte brut de type JSON. La bonne chose à propos de protobufs est que le code de version est généré pour vous. Dans la version 2 de votre format de fichier, il vous suffit d'ajouter des champs au fichier de définition .proto. La nouvelle version peut lire l'ancien format de fichier et laisse simplement les nouveaux champs vides. Ce n’est pas exactement pour cela que les protobufs ont été conçus, mais ils constituent un format de fichier binaire simple et efficace pour les messages personnalisés, et le code est généré pour vous.

Voir également le Thrift de Facebook, maintenant dans l'incubateur Apache.

Answer 4

Au fil des années, je me suis trouvé de plus en plus favorable au texte, à moins que ce ne soit tout simplement impossible. Les processeurs sont assez rapides maintenant que nous pouvons le décoder assez vite.

Évidemment, lorsque vous devez mettre à jour fréquemment de petits éléments d'information dans un gros fichier, ce n'est pas une option - mais cela décrit probablement une base de données.

Il faudrait une situation inhabituelle à ce stade pour me faire choisir autre chose que l'une de ces deux options.

Answer 5

+1 pour XML. A un peu de frais généraux, mais facile à analyser, lire et déboguer. Peut être strict, si vous utilisez un schéma. Facile à transformer avec XSLT, et très portable (en fil ou simplement dans une clé USB):

Answer 6

Cela dépend vraiment de la situation. Vous devrez examiner vos options par rapport aux réponses à diverses questions:

• Combien de données devez-vous stocker? Avez-vous besoin d’optimiser pour une représentation compacte?
• La performance des lectures / écritures est-elle critique? Avez-vous besoin d'optimiser l'accès au disque, la sérialisation et la désérialisation à faible impact?
• Avez-vous besoin d'un accès aléatoire dans le fichier? Avez-vous besoin d'optimiser la structure de recherche dans les données?
• Ces données seront-elles utilisées sur différents systèmes, éventuellement avec différents codages de caractères? Avez-vous besoin d'optimiser la portabilité?

La nature des données elle-même aura un impact. Est-ce une structure de liste plate? Est-ce un arbre? Est-ce un graphique cyclique? Les enregistrements ont-ils des largeurs fixes ou variables?

Une fois que les réponses à ces questions sont connues, vous pouvez choisir parmi vos options, en le gardant aussi simple que possible. Les options courantes (XML, CSV, YAML) conviennent souvent à vos besoins. Sinon, vous devrez développer votre propre formatage et vos propres procédures d'écriture et de lecture.

Answer 7

Il y a tellement de possibilités, mais le plus pragmatique doit être XML

• Il existe de bonnes bibliothèques XML pour presque toutes les plateformes de développement
• La plupart des plates-formes autorisent la sérialisation de graphe d'objet avec quelques lignes de code. XML est donc facile à implémenter
• La plupart des plateformes ont un lecteur en mémoire et / ou en streaming, vous pouvez donc gérer des fichiers très volumineux sans utiliser trop de mémoire
• La plupart des plates-formes fournissent un transformateur XSLT, vous pouvez donc déplacer des fichiers d'un format à un autre, même d'un format XML à un autre que XML
• Il existe des extensions d'indexation pour XML permettant de gérer également des fichiers très volumineux
• XML contient des fichiers XSD pour valider le format avant d'essayer de le lire
• XML est capable de représenter n'importe quel objet simple ou complexe
• Si la taille du fichier vous inquiète, il vous suffit de compresser le code XML final. Cette technique est utilisée dans Microsoft Office, etc.
• XML est toujours lisible par l'homme
• XML est une norme commune