Est-ce une mauvaise pratique de stocker des informations de métadonnées dans des noms de fichiers? De meilleures solutions?

J'ai remarqué où je travaille, les gens souhaitent stocker des informations dans les noms de fichiers et analyser les noms de fichiers.

Pour moi, cela ne semble pas être une bonne pratique. Je vois déjà les problèmes occasionnels avec les scripts globbing pour un fichier, et obtenir le mauvais parce qu'un autre fichier correspond en premier. Nous discutons également comment contourner les problèmes avec les séparateurs pour les champs.

Est-ce considéré comme une mauvaise pratique ou non?

Quelles sont les autres solutions acceptées pour récupérer des fichiers à partir d'un système de fichiers basé sur un certain type de métadonnées?

Oui, je pense que c'est une mauvaise pratique. Il est soumis à toutes sortes de problèmes - par exemple des limites de longueur, des problèmes d'encodage et des conflits dus à des données en double.

Il vaut mieux utiliser un "fichier maître" (parfois appelé manifeste ou index) qui contient des métadonnées et des chemins d'accès aux fichiers. Ou quelque chose de similaire dans une base de données, un registre ou autre chose. Ou pour placer les métadonnées dans les fichiers réels, au niveau supérieur de certaines infrastructures de données contenues dans le fichier, par exemple en JSON ou XML.

Ceci est quelque peu analogue au concept consistant à placer des informations ou des clés d'espacement de noms dans des magasins de valeurs-clés. Je pense que c'est correct tant que vous l'utilisez uniquement pour l'espace de noms et que vous effectuez des recherches rapides - les composants clés ne sont pas là pour fournir des informations analysables. Si vous avez besoin de ces informations, dupliquez-les dans la valeur (fichier dans le cas ci-dessus).

Premièrement, les métadonnées sont un concept flou.

Cela dit, de nombreux cas de métadonnées dans les fichiers existent déjà:

• numéros de version des bibliothèques
• date et heure des images, ou au moins index de séquence
• type de fichier, qui déclenche quelle application doit ouvrir le fichier
• nom de votre répertoire personnel, qui doit être votre nom d'utilisateur de session

Néanmoins, cette liste restreinte n'est pas un argument en faveur de la pratique.

Les alternatives sont:

• gérer les métadonnées au niveau FS, comme l'ancien HFS d'Apple par exemple
• mettre des métadonnées dans le fichier lui-même, comme Exif pour les images ou ID3 pour les sons
• placer les métadonnées dans un autre fichier ou dans une base de données, comme la plupart des gestionnaires de médias.

Il semble que vous ayez besoin d'une base de données.

Il existe de nombreux problèmes de sécurité lors de la mise en place des données utilisateur dans les noms de fichiers. Disons que vous avez un fichier pour chaque utilisateur ("username.txt"). Ce qui se passe ce que quelqu'un enregistre le nom d'utilisateur "../../../../etc/passwd" dépend de la façon dont vous filtrez les entrées utilisateur.

Les cadres de base de données vous aideront parfois à nettoyer les entrées des utilisateurs.

Non ... eh bien ... pas nécessairement.

Tant que vous avez une convention stricte et des moyens d'analyse et de validation communs (scripts, bibliothèques, etc.) facilement disponibles, vous êtes prêt à partir.

Prenons par exemple les systèmes de gestion des emballages et des dépendances (Maven, NuGet et autres). Bien que beaucoup utilisent des fichiers spécifiques pour les métadonnées pour stocker les informations les plus avancées, les informations de base font souvent partie du nom du fichier lui-même. En s'appuyant sur des conventions strictes, le nom de fichier peut contenir les informations les plus pertinentes sur le package: c'est le fournisseur, c'est le nom, c'est la version, c'est le type. Parfois, c'est tout ce dont vous avez besoin ... 4 ou 5 brèves informations.

Si les métadonnées sont simples, une convention de dénomination des fichiers est parfaitement logique et ne nécessite rien à mettre en place. Il peut être renforcé avec des outils et des scripts très simples, aucune base de données requise, aucune infrastructure spécialisée juste quelques scripts et une convention de dénomination.

Si rien là-bas ne fait tout à fait ce dont vous avez besoin et vos besoins sont simples, je commencerais par cela.

vos exigences dépassent cette convention? étendez-le avec un fichier de métadonnées approprié. Vous avez besoin plus tard d'une meilleure recherche pour cela? Il existe déjà de bonnes solutions pour rechercher des fichiers qui vous amènent là où vous en avez besoin.

Ce n'est pas que je n'aime pas les bases de données, bien au contraire, elles sont vraiment puissantes et utiles, mais elles nécessitent un certain temps supplémentaire pour démarrer. Ils doivent être installés, sauvegardés, maintenus, vous aurez besoin de personnel qui, s'il n'est pas entièrement dédié, devra consacrer une partie de son temps à cette infrastructure. Ils sont également plus complexes et cryptiques pour les profanes, perdent le développeur qui vous a mis en place et votre système sera coincé dans le temps jusqu'à ce que vous trouviez un remplaçant.

Ne sous-estimez jamais la puissance de la technologie de pointe avec la surveillance appropriée, elle peut vous faire avancer.

Et au moment où vous dépasserez votre solution de basse technologie, vous aurez rassemblé toute l'expérience et les exigences pour mettre en œuvre le système parfait pour vos besoins.

Tout d' abord, laissez - nous d' accord ce fichier est . Un fichier est une donnée packagée avec un nom qui peut être transmis, reçu, créé et supprimé avec (très proche) des opérations atomiques.

De nombreux systèmes de fichiers (Mac OS et systèmes de fichiers Linux plus récents) implémentent des «fourches», souvent utilisées pour stocker des ressources et des métadonnées. Cette approche du stockage des métadonnées était problématique dans la mesure où les méthodes de transfert réseau traditionnelles, les méthodes de sauvegarde et de restauration et les méthodes de copie de fichiers étaient incohérentes, en particulier lorsque les systèmes de fichiers source et de destination comprenaient les fourchettes de fichiers différemment.

Le nom de fichier est utilisé pour contenir des métadonnées car a) il est toujours là, b) des métadonnées ont toujours été présentes dans le nom de fichier (au moins dans l'utilisation des extensions de fichier), et c) le nom de fichier subit très peu de traduction lors du déplacement entre les systèmes (distinctions de casse, limitations de jeu de caractères, limitations de caractères).

Ainsi, le nom du fichier est visible, portable et gérable. Ce n'est pas une mauvaise chose pour stocker certaines métadonnées.

La meilleure solution pour traiter les métadonnées de fichier générales est probablement d'utiliser un référentiel de contenu , où le référentiel de contenu peut être configuré avec le schéma de métadonnées à utiliser pour les fichiers. Dans de nombreux cas, c'est exagéré, mais, à mon humble avis, c'est la voie à suivre pour une gestion sérieuse des métadonnées.

Mon point de vue est que vous avez peut-être vu du code quelque part qui fait des choses bâclées ou cassantes avec les noms de fichiers, mais cela ne signifie pas que "stocker des métadonnées dans des noms de fichiers" est mauvais en général.

Les noms de fichiers sont des métadonnées - ce sont des données sur les données du fichier, indépendamment des données du fichier lui-même. En fait, les noms de fichiers sont si anciens qu'ils sont probablement l'exemple canonique des métadonnées.

Si vous considérez que les extensions de fichier ne sont que la partie finale du nom de fichier, le concept de nom de fichier en tant que métadonnées devient encore plus inévitable.