sur les avantages et inconvénients entre les 2 formats
Des données stockées en fichier texte c'est facilement
1. modifiable dans un éditeur de texte;
2. lisible par un programme ad-hoc même si on n'a besoin que d'un bout de la donnée;
3. produisible par un programme ad-hoc;
en revanche
l'accès direct aux données est difficile ou impossible;
le format est souvent sous-défini et facile à imiter, on a parfois tout un tas de formats cousins mais pas forçement compatibles. (Genre CSV, y'en a des gros, y'en a des p'tits, des mignons et des pas jolis.)
En gros le format texte a l'intérêt qu'on peut accéder à ou produire de tels fichiers sans passer par une psychothérapie avec l'API d'une quelconque bibliothèque — qui au passage n'a aucune raison d'exister pour le langage que tu as décidé d'employer.
Par exemple sox peut convertir des fichiers sonores dans un format texte, dans n'importe quel langage de programmation il ne faut pas plus de 20 minutes pour écrire une procédure de lecture pour ce genre de fichiers.
Idem pour les images avec les formats PNM et PPM.
Ensuite par exemple, si tu veux modifier un document TeX ou HTML dans un traitement par lot c'est très facile (tant que tu sais bien décire la modification à faire).
Des données stockées dans un format binaire…
1. c'est impossible à lire ou écrire sans un composant logiciel spécialisé
2. le format est bien défini
3. il est possible d'accéder aux données aléatoirement.
En ce qui concerne systemd je pense que le choix du binaire pour les logs n'est pas utile: pour le stockage et la lecture occasionnelle les fichiers texte conviennent, pour les manipulations complexes il vaut sûrement mieux déplacer les logs dans une base de données relationnelle que de les stocker dans un format de fichier binaire.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Michaël (site web personnel) . En réponse à la dépêche Documentation du format du Journal. Évalué à 6.
Des données stockées en fichier texte c'est facilement
1. modifiable dans un éditeur de texte;
2. lisible par un programme ad-hoc même si on n'a besoin que d'un bout de la donnée;
3. produisible par un programme ad-hoc;
en revanche
En gros le format texte a l'intérêt qu'on peut accéder à ou produire de tels fichiers sans passer par une psychothérapie avec l'API d'une quelconque bibliothèque — qui au passage n'a aucune raison d'exister pour le langage que tu as décidé d'employer.
Par exemple sox peut convertir des fichiers sonores dans un format texte, dans n'importe quel langage de programmation il ne faut pas plus de 20 minutes pour écrire une procédure de lecture pour ce genre de fichiers.
Idem pour les images avec les formats PNM et PPM.
Ensuite par exemple, si tu veux modifier un document TeX ou HTML dans un traitement par lot c'est très facile (tant que tu sais bien décire la modification à faire).
Des données stockées dans un format binaire…
1. c'est impossible à lire ou écrire sans un composant logiciel spécialisé
2. le format est bien défini
3. il est possible d'accéder aux données aléatoirement.
En ce qui concerne
systemdje pense que le choix du binaire pour les logs n'est pas utile: pour le stockage et la lecture occasionnelle les fichiers texte conviennent, pour les manipulations complexes il vaut sûrement mieux déplacer les logs dans une base de données relationnelle que de les stocker dans un format de fichier binaire.