目前，我正在尝试提出一个文件和文件夹的命名约定，本质上是一种将服务器上的 400 多万张图像分散到各个目录或其他位置的方法。
我想找出最好的处理方法。并不是说如果需要的话将所有图像分成几组，或者重命名它们以防止将来发生冲突，或者诸如此类的事情。我不是在寻找这方面的答案；我会想出一种方法来做到这一点。我想得到的答案是，构建文件夹结构以拆分这些图像的最佳方法是什么，不仅现在重命名文件，而且将来命名文件时应遵循什么样的良好命名约定。以及文件夹应遵循什么样的良好命名约定？
我问这个问题只是因为我的印象，采用一个单独的文件夹，无论是在单个服务器上还是跨集群网格或云样式（哪个网格在计划中，只是不在当前预算中）都不是最好的方法，因为它会在读/写时间上造成额外的负载，无论发生什么，都会及时查看文件是否存在，然后为其提供服务。
我知道这似乎是一个很宽泛的问题。但最终还是要通过命名约定和存储约定来维护优化的环境。
通过命名约定，我将举一个例子。Facebook，当你查看它的图像时，文件名类似于 GUID，但不完全一样。但我知道该约定也有一定的逻辑。所以再次有点开放，因为最终我不知道我在这里到底在问什么，甚至不知道我问的是否正确，但我希望有人能引导我朝着正确的方向前进。
答案1
没有任何。
- 使用 GUILD 作为文件名。使用它们也可以形成文件夹结构（前 2 个字节，然后 32 个字节等）。
- 使用数据库将名称映射到 GUID。
然后，您可以移动存储的各个部分（文件夹层次结构甚至不必是层次结构），并且重命名不产生任何成本（文件上的名称保持不变）。您还可以轻松处理双重名称 - 它们根本不会在存储方面发生。
最后，当你管理这么多项目时，没有人会逐一查看它们。无论如何，你都会开始拥有所有权、标记等，而这需要一个数据库。然后真实姓名就很麻烦了。摆脱它们，使用身份名称（即只说“这是项目参考编号 X”的名称），GUID 就是这样做的。