因此,您正在编写一个 Web 应用程序,并且您有几个网站区域可供用户上传文件。我的基本工作方法是将实际文件存储在服务器上,并有一个数据库表将存储的文件名连接到它所关联的记录。
我的问题是:每种“类型”的文件是否应该有一个不同的表?此外,文件应该存储在服务器上与上下文相关的位置,还是一起存储?
一些示例:用户个人资料照片、求职简历、CMS 页面上的相关文档等。
因此,您正在编写一个 Web 应用程序,并且您有几个网站区域可供用户上传文件。我的基本工作方法是将实际文件存储在服务器上,并有一个数据库表将存储的文件名连接到它所关联的记录。
我的问题是:每种“类型”的文件是否应该有一个不同的表?此外,文件应该存储在服务器上与上下文相关的位置,还是一起存储?
一些示例:用户个人资料照片、求职简历、CMS 页面上的相关文档等。
从您的示例中,有两个表的参数,因为您有可以与两个不同事物关联的文件。
如果您将它们放在一个表中(并且您希望允许用户拥有不止一张照片或简历),那么您需要两个链接表来关联文件->用户和文件->cms_pages。可以说,这意味着 HABTM 关系,这是不正确的并且允许不一致的数据。
两个表的方法稍微干净一些,并且只允许文件与具有简单 belongsTo 关系的正确类型的实体相关联。
但我认为这个问题没有任何“正确”的答案,除非您需要为不同的文件类型存储不同类型的元数据。
还要确保存储或能够计算每个文件的 mimetype,以便可以使用正确的 HTTP 标头正确地将其返回给浏览器。
根据您所说,我只会将具有随机(UUID 或其他)文件名的文件存储在一个地方。然后我会有一个“附件”表或包含对所有外部文件的引用的东西。该表还将包含该文件的元数据,它是什么类型的文件(图片、简历等)等等。
但是,一个目录中的文件数量可能会有硬性限制,具体取决于您使用的 FS。
将不同文件存储在不同位置可能有多种原因。
首先,可能需要考虑限制一个目录中的文件数量。
其次,安全性可能是一个问题——如果一些是公开可见的(例如个人资料照片),而另一些则不是(例如简历),那么将它们放在不同的目录中会更容易管理。
第三,如果文件被拆分、例如在文件资源管理器中浏览、管理备份或修改应用程序以将文件存储拆分到多个位置,则简单的管理任务可能会更容易。
还有文件名冲突的问题,但是如果您重命名所有内容以匹配数据库 id 字段(例如),那么这将不是问题。
但归根结底,这可能取决于数量和您自己的偏好。
仅当您为每种类型的文件存储其他元数据(因此,附加列)时,每种文件类型的不同表才会变得相关。如果每种文件类型的表只包含相同的列(例如,文件名、文件类型、上传日期等),那么将它们全部放在一个表上是有意义的。