| Peuwi |
Bonjour, j'ai un cas concret dans mon SI où l'on doit définir un format de fichier unique comme source d'alimentation standardisée. (c'est un projet assez global quand même)
-> Je précise bien, c'est le format de transfert de données "légèrement" relationnelles de BDD à BDD : c'est des paquets de 100.000 enregistrements 100.000 "fiches" qu'on envoi, pas un bête fichier de conf, ni un descripteur de véhicule spacial, ni un métalangage de compilation transquantique, ni un remplacement temporaire de BDD ... Avant, on avait un fichier plat qui faisait (mal) le boulot. (mal, parce que même avec un fichier plat, il y avait moyen de faire des conneries) Pour des raisons politiques, on va avoir du xml.
La question, c'est : ca apporte quoi ? (par rapport à un fichier plat, type csv) Donc, avec ma non-connaissance, ca donne : Avantages :
- c'est hiérarchique (oui, oui, et c'est génial d'ailleurs ... Bon, dans notre SI, on remarque que le schéma de donné ne vole pas très haut non plus, c'est souvent du 1-1)
x c'est auto-descripteur, donc universel (mais un fichier plat aussi peut être auto descripteur avec l'entête des colonnes)
x c'est un format universel, trivialement lisible ou ecrivable par tous les outils (mais pas mieux qu'un fichier plat ... On peut pas faire plus simple qu'un fichier plat)
- inutile de croiser les lignes pour lire un enregistrement hiérarchique complet (ca, c'est pratique ... Il fallait forcément une BDD pour régénérer la hiérarchie d'un plat : il fallait recroiser les lignes)
x il est très robuste pour envoyer des données universelles (sauf qu'on envoi pas nos données à l'univers, on s'appelle pas google. Globalement on envoi toujours la même chose)
- le format un peu plus complexe permet de retirer certaines décisions de ceux qui ne maîtrisent pas le sujet. (notamment avec un xsd qui part directement d'une équipe technique vers une équipe technique)
- le format plus complexe permet d'éliminer des possibilités d'âneries (exemple : l'ajout des colonnes blanches "au cas où" ) Inconvénients :
- c'est 3 fois plus volumineux, 10 fois plus difficile à traiter, surtout sur de gros volumes (inconvénient minime, je l'accorde)
- c'est illisible par un humain contrairement au fichier plat (et ce n'est plus minime, ca interdit la source d'alimentation "humains" sans utiliser un outil supplémentaire, lequel est généralement moins cool qu'excel) (petit bémol : les fichiers plat trop gros redeviennent illisibles)
- c'est plus difficile à lire qu'un fichier plat (selon les outils, à commencer par le spécifique : ya plein d'api, certes, mais ca restera toujours plus difficile que du csv)
- ya 5 fois plus de possibilités de faire des conneries avec du xml (les attributs qui vont se retrouver dans les données, la hiérarchie mal foutue, les attributs encore plus mals nommés, xsd abusivement contraignant, 50% des réunions à recommencer avec une explication du format, et 50% des décisions prises avec incompréhension du format, erreurs structurelles à la création du format ...). Je dis pas que c'est compliqué, c'est aussi simple que faire du vélo. Mais faire un fichier plat, c'est aussi simple que marcher, et ya encore 5% des gens qui ne peuvent pas marcher.
x le xml ne règle pas tous les problèmes : il faut toujours un mapping en entrée & sortie, lequel peut toujours être faux, et un fichier xml peut toujours être fonctionnellement incorrect (avec à la fois un "name" et un "nom" par exemple), donc il faut toujours le valider. (mais ce ne sont pas un inconvénient nouveau)
Ca, c'est ce que je vois (et que je trouve sur Wikipedia)
Maintenant, du xml, on en fera, et les inconvénients, si je les ai ratés, on les découvrira sur le tas. Par contre, si j'ai oublié des avantages, on risque de passer à coté.
- documentation de mapping automatique ?
- possibilités d'évolutions vers une plus grande intelligence et/ou de meilleurs outils et/ou de meilleures ressources ?
- effet constructif sur le long terme des contraintes ? (du style UTF8 ?)
Merci ! |
