我将托管用户提交的文件。我需要从文件中获取一些数据，然后将其移动到某个目录。
此文件的生命周期有两个兴趣点。第一个是数据被抽象化的时候，第二个是文件被归档以便可以共享的时候。
当数据被抽象时，我认为将文件重命名为唯一的文件或将唯一的字符串附加到文件名以防止它覆盖其他现有文件。
当文件要归档时，我想到了三种策略。一种是将从某个数据上传的所有文件保存在一个文件夹中。(2006/sept/04, 2008/jan/05) 另一种方法是保留一个文件夹并继续填充它，直到我想保留在文件夹中的文件达到最大数量，然后再创建一个（/folder001/、/folder002/、 /folder003/ 等）。另一种方法是在达到某个阈值时创建子文件夹。所以就像 (/j/jd/jde/jdelator) 我在 unix 中看到过这个，不知道如何解释。
我的问题是你们发现有用或使用过什么样的策略？
当数据被抽象时，我会选择这样的东西：filename + millisec();
两次对毫秒的调用不太可能相同，并且文件名在访问时更加用户友好。
如果您决定删除旧的和未使用的文件，日期策略可能会很方便：您只需要获取 2006 文件夹，并根据您的日志删除去年未访问的所有文件。这对您的用户来说也是一个很好的指示，因为他们会知道它是否是一个新文件。folderXYZ 只是这个的一个变种，用每个 N 个文件的标签替换 date。
阈值子文件夹可帮助您将目录的条目数保持在较低水平，因此访问速度更快。请注意，此解决方案有时需要在特定目录增长时移动文件（如果未映射，则破坏某些 url）。
另一种可能性是使用与文件名位置对应的 UID 的数据库，并通过http://server.com/UID/filename.txt访问文件。这样，用户将文件保存为“filename.txt”，这对他来说很方便，并且您可以通过 URL 知道在哪里找到文件（使用 DB 将 UID 转换为位置）。请注意，UID 可以是校验和（MD5、SHA-1）来处理同一文件的重复项。
我会在数据库中使用 guid 进行投票，然后在必要时使用 Content-Disposition 标头将其命名回原始文件名。我要提倡的一件事是，您使用的文件夹存储在 Web 根目录之外；您不希望用户将文件上传到您的应用程序文件夹中。
我使用了一个关系数据库，它将 ID（int）标记为文件名 uuid。这样，它们在磁盘上的位置就无关紧要了。它可以帮助我混淆文件。此外，我可以使用 JOIN 任意“重命名”文件。此外，我可以使用不同的文件“名称”。这完全取决于您的应用程序及其运行位置。
虽然这取决于您的应用程序等，但我建议暂时保持文件存储库方案非常简单，稍后再决定更详细的策略。换句话说，你制造了一段时间的“管理混乱”；结构和策略稍后会出现，当您会发现所有需求和领域细节时。通过保持简单，您可以轻松更改所有内容。
无论如何，改变是不可避免的，你现在能做的最好的事情就是选择一些策略并记录一切。