我注意到我在哪里工作，人们热衷于在文件名中存储信息并解析文件名。
对我来说，这似乎不是特别好的做法。我已经看到脚本偶尔会遍历一个文件的问题，并且由于另一个文件首先匹配而出现错误，我们也正在讨论如何解决字段分隔符的问题。
是否被认为是不良做法？
基于某种类型的元数据从文件系统中检索文件的其他公认解决方案是什么？
Answers:
是的，我认为这是不好的做法。它会遇到各种各样的问题-例如长度限制，编码问题和由于重复数据而引起的冲突。
更好的方法是使用包含元数据和文件路径的“主文件”（有时称为清单或索引）。或数据库中类似的东西，注册或其他。或者将元数据放在实际文件中，位于文件中某些数据结构的顶层，例如JSON或XML。
这有点类似于在键值存储中放置信息或命名空间的概念。我认为这是可以的，只要您仅将其用于命名空间并进行快速查找-关键组件就无法提供可解析的信息。如果需要该信息，请将其复制到值（上述情况下的文件）中。
听起来您需要数据库。
将用户数据放入文件名中存在很多安全问题。假设您为每个用户都有一个文件（“ username.txt”）。有人注册用户名“ ../../../../etc/passwd”会发生什么情况，取决于您过滤用户输入的方式。
数据库框架有时会帮助您清理用户输入。
不...很好..不一定。
只要您有严格的约定并且可以使用常用的解析和验证手段（脚本，库等），您就可以使用。
以打包和依赖管理系统（Maven，NuGet等）为例。尽管许多人会将特定文件用于元数据来存储更高级的信息，但基本信息通常是文件名本身的一部分。根据严格的约定，文件名可以包含有关软件包的最相关信息：它是供应商，它的名称，它的版本，它的类型。有时候，这就是您所需要的... 4或5条简短的信息。
如果元数据很简单，则文件命名约定非常合理，无需放置任何内容。可以使用非常简单的工具和脚本，不需要数据库，不需要专门的基础结构，只需几个脚本和命名约定来增强它。
如果那里什么也没做，那么您需要什么，而您的需求很简单，我将从这里开始。
您的要求超出了这个约定？用适当的元数据文件扩展它。您以后需要对此进行更好的搜索吗？已经有不错的解决方案来搜索文件，使您到达所需的位置。
并不是我不喜欢数据库，相反，它们确实功能强大且有用，但是它们需要一定的开销才能运行。他们需要安装，备份，维护，您将需要一些工作人员，如果他们不是完全专职的话，则需要将部分时间用于此基础架构。对于外行来说，它们也更复杂，更隐秘，失去了设置您的开发人员，您的系统将被困在及时位置，直到找到替换的设备为止。
切勿过分低估低端技术的力量，适当的监督可能会让您漫漫长路。
而且，当您不再使用低技术含量的解决方案时，您将已经积累了所有经验和要求，可以实施满足您需求的完美系统。
首先，让我们同意文件是什么。文件是打包的数据，其名称可以通过（非常接近）原子操作进行发送，接收，创建和删除。
许多文件系统（Mac OS和更新的Linux文件系统）实现了“ forks”，通常用于存储资源和元数据。这种存储元数据的方法存在问题，因为传统的网络传输方法，备份和还原方法以及文件复制方法不一致，尤其是当源文件系统和目标文件系统对文件派生的理解不同时。
文件名用于保存元数据，因为a）始终存在元数据，b）文件名中始终存在元数据（至少在使用文件扩展名的情况下），以及c）移动时文件名很少经过翻译系统之间的区分（区分大小写，字符集限制，字符限制）。
因此，文件名是可见的，可移植的且可管理的。对于存储某些元数据来说，这不是一件坏事。
解决通用文件元数据的最佳解决方案可能是使用内容存储库，其中可以使用要用于文件的元数据架构配置内容存储库。在许多情况下，这是过大的了，但是恕我直言，这是进行认真的元数据管理的方法。