我应该将文件信息存储在基于 php 的文件管理器的数据库中吗？
我正在寻找为我正在开发的系统构建一个基本的文件管理组件（php、javascript、sencha）。我试图以一种或另一种方式说服自己是否需要在数据库中存储有关通过系统管理的文件的额外信息。一方面，我不愿意通过尝试确保存储在数据库中的信息反映在文件系统中来使简单的设计复杂化。我想如果他们因为某种原因变得不同步，一场噩梦就会随之而来。即路径未正确更新。依赖文件系统中的内容似乎更容易。我不需要任何像ACL这样的控制机制。
在大多数情况下，目录结构对用户是隐藏的，因为他们实际上并不关心它们存储在文件系统中的位置。有点像电子邮件附件。附件与数据库中的其他数据相关。我最初的想法是通过使用目录在文件系统内创建关系。例如：
根
...Project_id_1
......主题_id_1
……主题_id_1
……主题_id_2
……主题_id_3
......主题_id_2
......主题_id_3
...Project_id_2
...Project_id_3
该 ID 也是与其相关的数据库中项目的记录 ID。我认为这会很好地工作，除非我需要将其显示为树视图。我需要提取每个目录的关系，以便可以显示有意义的名称。也许这是对其他地方获得的简单性的一个很好的权衡。即不必在每次主题名称更改时重命名目录。
如果我确实决定在数据库中存储有关每个文件的更多信息，那么除了有用（但不是必要）的信息（例如上传者、日期等）之外，我还会获得什么。当然，我应该考虑其他任何其他原因设计也会受到赞赏。大多数 OTS 的东西要么提供了太多我不需要的功能，要么需要太多工作来改造系统。
I'm looking to build a basic file management component for the system I'm working on (php, javascript, sencha). I'm trying to convince myself one way or the other on whether I need to store extra information in a database about files being managed through the system. On one hand, I'm reluctant to complicate a simple design by trying to ensure that information stored in the database is reflected in the filesystem. I imagine a nightmare ensues if they become out of sync for whatever reason. I.e. the path is not updated correctly. It just seems easier to rely on whats in the filesystem. I don't need any control mechanisms like ACL.
For the most part, the directory structures are hidden from the user as they really don't care where in the filesystem they are being stored. Kinda like email attachments. The attachments are related to other data in the database. My initial idea was to create the relationship within the filesystem by using directories. For example:
Root
...Project_id_1
......Theme_id_1
.........Topic_id_1
.........Topic_id_2
.........Topic_id_3
......Theme_id_2
......Theme_id_3
...Project_id_2
...Project_id_3
The ID would be the record ID of the item in the database its related too. I think this would work just fine, except when I need to display this as a tree view. I will need to extract the relationship for each directory so I could display meaningful names. Maybe this is a fine trade off for the simplicity gained elsewhere. I.e. not having to rename directories with every topic name change.
If I did decide to store more information in the DB about every file, what would I stand to gain besides useful (but not necessary) information like who uploaded it, date, etc, etc. Of course, any other reasons I should consider other designs would be appreciated as well. Most of the OTS stuff, either offers too much functionality I don't need or be too much work to retrofit into the system.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我想关键问题是您存储的附加信息是否具有足够的价值，值得这么麻烦。如果你建造它，他们会来吗？
我见过很多系统，其中有人做了很多工作，却懒得问“有人会关心吗？”
我不知道您的用户想要什么或需要什么，因此如果没有更多信息，我无法回答您的问题。
更新
回复您的评论：
当我需要跟踪关系时，我已将有关文件的信息存储在数据库中。我想到的第一个例子是一个 Web 应用程序，用于跟踪我们组织生产的设备的建议设计更改，用户可以在其中添加附件（更详细的 Word 文档、工程图纸等）到他们的建议中，这些附件将被上传并与设计变更记录。因此，我们将所有这些文件扔到某个目录中，然后在数据库中为每个附件都有一条记录，将其与设计变更记录联系起来。我现在忘记了除了设计变更记录的键和文件名之外是否还有任何数据，但肯定可能有诸如何时上传、由谁上传等信息。
I guess the key question is whether the additional information you store would be of sufficient value to be worth the trouble. If you build it, will they come?
I've seen lots of systems where someone went to a lot of work without bothering to ask, Will anyone care?
I don't know what your users want or need, so without a lot more information I can't answer the question for you.
Update
In reply to your comment:
I have stored information about files in a database when there were relationships that I needed to keep track of. The first example that comes to mind is a web app for tracking suggested design changes to equipment our organization produced, where users could add attachments (Word docs with more detail, engineering drawings, whatever) to their recommendations that would be uploaded and associated with the record for the design change. So we tossed all these files in a directory somewhere, and then in the database had a record for each attachment that tied it back to the design change record. I forget now if there was any data in there besides the key of the design change record and the file name, but there certainly could have been things like when uploaded, by whom, etc.
我会说：
今天：不。不要根据未来可能的需要来创造工作。
为了明天？是的，只要您确实需要就可以。您提到您已经拥有一个数据库，因此您不必承担大量开销。
I would say:
For today: no. Do not create work based on a possible future need.
For tomorrow? Yes, as soon as you actually need to. You mention you already have a database, so its not like you have to bite off a lot of overhead.