Y a-t-il des avantages à un format de fichier à largeur fixe sur quelque chose comme XML? Je réalise que XML occuperait probablement plus d'espace disque pour stocker la même quantité de données, mais le fichier pourrait également être compressé. Je suppose que vous pourriez aussi, en théorie, lire une pièce spécifique de données basée sur l'endroit où elle se trouve dans le fichier (attrapez simplement ces octets). Mais autre que ça, quoi d'autre?
6 Réponses :
Une des raisons pourrait être que le traitement XML (non seulement la lecture et le chargement dans des structures de mémoire, mais pensez à la recherche de regex dans un fichier XML contre une simple largeur fixe ou délimitée, ou même faire des corrections rapides manuelles aux données incorrectes ) est plus compliqué que les fichiers de largeur fixe. Bien sûr, il existe de nombreuses bibliothèques qui peuvent le faire pour vous maintenant, mais s'il n'y en a pas pour la plate-forme que vous travaillez, voulez-vous vraiment écrire un analyseur XML ou un programme qui vient de lire n octets à l'emplacement x ?
Probablement principalement pour des raisons héritées, car des analyseurs pour XML, JSON (etc.) existent à peu près toutes les plateformes.
Les formats théoriquement à largeur fixe peuvent être plus peu spatiaux, comme vous le suggérez; et un peu de lecture plus simple. Mais ceux-ci ne semblent pas être des avantages importants.
Pour ce que cela vaut, des formats tabulaires (mais pas à la largeur fixe) comme CSV ont leurs utilisations, combinant une représentation plus compacte plus compacte et éventuellement une lisibilité mieux; CSV fonctionne assez bien pour les travaux de carte / de style.
XML est compliqué. Et surtout si vous faites validation selon un schéma. Cela peut ne pas sembler important, car quelqu'un d'autre a déjà écrit XML analyseur que vous pouvez utiliser. Mais cela ajoute beaucoup de traitement, ce qui signifie qu'il faut plus de temps. Cela peut ne pas être un problème dans de nombreux cas, mais parfois.
Si vous souhaitez enregistrer un entier dans un format de fichier personnalisé, il ne faut que 4 octets et lorsque vous souhaitez le charger, vous copiez simplement ces 4 octets en mémoire (en supposant que le format de fichier et votre plate-forme a la même endansion). . Mais avec XML, il peut prendre quelque chose comme 10-30 octets. Et le chargement, il s'agit de comparer des chaînes et d'analyser les représentations décimales des entiers et probablement plus.
Encore une fois, ces différences de taille de performance et de stockage peuvent très bien être trop minuscule pour que vous puissiez même envisager (et le travail qu'il faudrait au format personnalisé pourrait être non trivial), mais dans de nombreux cas, ces différences faire matière.
Par exemple, j'ai rencontré un système utilisant des messages SMS pour la transmission de certaines données. Cela signifie que vous avez 140 octets (!) Par message. Et le dispositif qui envoie et reçoit ces messages n'a pas de mémoire et GBs GHz de CPU. Dans cette situation, vous vous assurez que chaque bit compte et vous n'utilisez certainement pas XML.
Merci d'avoir répondu. Cependant, je dirais qu'un fichier de largeur fixe complexe est plus confus qu'un fichier XML complexe. Au moins, vous pouvez lire le fichier XML!
Je n'ai toujours aucune idée du type de formats de largeur fixe parlez-vous, donc je ne peux donc pas répondre à cela.
Lorsque les données sont grandes (giga / terra-octets), les fichiers de format de largeur fixe peuvent être Étant donné que chaque enregistrement et chaque champ a des tailles fixes, vous pouvez simplement rechercher (par exemple) la n-millionième rangée et lire quelques enregistrements à partir de là. Vous pouvez également plan en mémoire le fichier entier en mémoire et obtenir un accès aléatoire plutôt efficace et facile à tout.
Les fichiers XML ne sont pas un bon ajustement dans ces cas.
"peut être" - oui. Mais pas toujours. Je me souviens d'une application COBOL réécrite dans un 4GL et a couru quatre fois plus vite; Sur investigation, le gain de vitesse était entièrement dû à l'utilisation de champs et d'enregistrements de longueur variable. Cobol dépense tout son temps à faire un rembourrage spatial inutile pour remplir la largeur fixe.
J'ai aussi eu les mêmes questions jusqu'à ce que je réalisais la puissance de la largeur fixe. Nous avons une table contenant des millions d'enregistrements les extraits dans un fichier en tant que JSON enflammé la taille du fichier sur 15 Go et 2 + heures. Tout en utilisant la largeur fixe l'apporté à 6,5 Go et 15 minutes.
extraction et écriture d'une largeur fixe est plus rapide que JSON.
J'ai essayé aussi de CSV et même ici la largeur fixe marquée mieux.
Je sais que c'est vieux, mais je traite à la fois de largeur fixe et de XML tous les jours. Vous pouvez très bien résumer jusqu'à:
xml = lisibilité
largeur fixe = vitesse et faible consommation de ressources
XML est largement destiné à la lisibilité par un humain. Je me fiche de ce que quelqu'un dit de la structure et de la validation. Si vous exécutez un système qui ne nécessite vraiment pas et que vous devriez avoir des humains en train de lire les fichiers, vous passez d'avant en arrière, vous en ajoutez-vous vraiment à la quantité de temps nécessaire pour traiter le fichier et à la Taille du fichier, affectant la durée pendant laquelle le fichier peut prendre pour transférer le contenu de son état ainsi qu'un autre impact sur le traitement. Tout cela aura également un impact sur l'utilisation de la mémoire par le système consommant le fichier XML. Il y a des avantages cependant à XML. Vous pouvez plus de définir votre structure plus vaguement. Parfois, il est plus facile si votre fichier et votre code ne nécessitent pas tous les deux de longs caractères de 255 caractères. Seulement que votre code charge cette période limite. Un autre avantage est que XML peut / devrait venir avec un schéma XML qui définit les exigences du contenu XML. Cela aide à avoir plusieurs systèmes qui consomment une seule API. Si vous pouvez fournir votre schéma à un développeur, ils peuvent facilement faire des objets dactylographiés qui se sertissent dans des XML formatés et structurés corrects.
La largeur fixe est destinée à la vitesse et à une consommation de ressources minimale. Il peut être plus fastidieux pour configurer que XML. S'assurer que tous les systèmes connaissent des positions exactes des «colonnes» dans le fichier de largeur fixe. Souvent, tous les systèmes n'utilisent pas les mêmes ou toutes les colonnes, vous ne vous retrouvez que un seul système qui comprend pleinement le contenu de la largeur fixe. Cela peut empêcher de développer une API ou un système utilisant votre contenu de fichier transféré. Cependant, parce qu'il n'y a pas d'étiquettes de champ, aucune balise, rien que des données brutes, vous pouvez souvent obtenir un colis plus petit envoyé sur le fil. Pas toujours vrai, dans certains cas, vous pouvez avoir un grand nombre de champs de texte communiqués à de petites quantités de données stockées dans les champs, mais doivent conserver une largeur de colonne de grande taille pour un cas de désactivation où une longueur de paragraphe était entrée. Maintenant, vous avez un tas de positions de maintien de l'espace blanc dans votre fichier de largeur fixe et XML peut réellement réduire votre taille d'emballage globale.
En règle générale, XML est destiné à la lisibilité. Vous ne pouvez généralement rien prendre d'un fichier de largeur fixe ou même d'un fichier CSV et commencez immédiatement à saisir à quel point les données. Où aussi étiqueté des fichiers XML, vous pouvez.
Il y a un certain nombre d'avantages et d'inconvénients que je ne suis pas allé dans, mais c'est là que je vois la vraie viande et les pommes de terre des différences.
J'ai vu un livre blanc il y a des années où une entreprise a examiné son utilisation de réseau et 75% de la bande passante était inutile XML allant entre les "services" internes. Cela ne compte même pas que la CPU a brûlé dans l'analyse. XML a sa place, tout comme tous les autres outils, mais il a été transformé en un diable d'un marteau et beaucoup de gens sont allés chercher des ongles et les ont trouvés partout.
Formats de fichier pour quoi? Voulez-vous des images ou une vidéo comme XML comprimé?
Non, je ne le fais vraiment pas. Je ne sais pas quel genre de formats de fichiers parlez-vous et ce n'est pas clair pour moi de votre question. Peut-être que je n'ai pas rencontré ces formats. Pourriez-vous préciser cela plus explicitement?
Je n'ai pas vu de format de fichier à largeur fixe pendant des années. Je pensais qu'ils sont morts avec des cartes perforées. Ils sont très efficaces bien sûr, mais ont un potentiel de changement zéro.
J'ai déjà semblé pour les journaux de puits (forage) et pour des informations géologiques, telles que CANSTRAT. Habituellement, ce sont des fichiers hérités et peuvent venir d'équipement / aller à l'équipement qui n'a tout simplement pas été mis à jour depuis longtemps. Parfois, ces fichiers sont également imprimés sur des imprimantes à matrice DOT et la largeur fixe garantit qu'il reste dans la limite de largeur (c.-à-d.: 72 caractères).
Tant qu'il y a des ordinateurs centraux et un cobol, il y aura des formats de fichier à largeur fixe.
Je vais necro ce post. @Michaelkay Data Warehousing utilise des fichiers de largeur fixe comme fou, même à cette journée. Personnellement, pour le travail de base de données, je préfère la largeur fixe sur tout format délimité ou hiérarchique 24/7.