我有一个具有自动增量ID作为主键的数据库表。
对于该表的每条记录,我最多可以有3个文件,这些文件可以公开使用,因此不是必须生成随机文件名,而这些文件是可选的。
我想我有2种可能的解决方案:
将随机生成的文件名存储在3个可为空的varchar列中,并将所有文件存储在同一位置:
不要存储文件名,而是将它们放在特定的文件夹中,并使用与主键值相同的名称命名:
在最后一个解决方案中,我知道uploads/a/1.jpg
属于带有的记录ID 1
,并且是type文件a
。但是我必须检查文件是否存在,因为文件是可选的。
您是否认为所有这方面都有良好的做法?还是有更好的方法?
如果您要谈论的文件是要由用户显示或下载的(无论是访问者还是经过身份验证的用户,是否按角色(ACL)过滤),请务必(IMHO)确保该用户将无法使用猜测除了已发送给他的有关资源的内容以外的其他信息。没有完美的解决方案可以毫无例外地适用于所有情况,因此让我们以一个示例为例进行更多说明。
为了增强敏感数据的安全性和整体不透明性(例如针对的特定情况)uploads/users/7/invoices/3.pdf
,我认为确保绝对没有人能够猜测可能与用户或任何其他实体关联的文件数量是明智的(否则,在此示例中,我们可以想象可能存在其他可访问文件-1.pdf和2.pdf)。通过设计,我们通常希望在定义明确且特定的案例和上下文中提供对文件的访问。但是,对于每个人都希望看到的图像文件(例如个人资料照片),情况可能并非如此。这就是为什么上下文在某种程度上很重要。
如果您选择保留自动递增的标识符作为引用文件的名称,这还可以提供有关存储在数据库中的数据大小的信息(/uploads/invoices/128.pdf
通知您服务器上可能已经有127张发票),并可能导致不道德的行为人们尝试获取永远不应该从定义的上下文中获取的资源。如果您选择使用某种唯一的生成的标识符(GUID),这种情况可能不太明显。
我建议您阅读这篇文章,以了解要为每个上载或创建的文件存储在数据库中的(G)/(U)UID(128位十六进制数字)的生成。如果您使用的是最新版本的MySQL,则甚至可以将这种标识符托管在一种binary (16)
可以自动转换为UUID的类型中,我将让您阅读与我所涉及的话题相关的有趣话题。/uploads/invoices/b0016303-8e4f-487a-8c30-5dddf1ebf7e9.pdf
只要您确保生成的标识符是唯一的哈希,它可能会输出更好的结果。
在这里,我对谈论性能问题似乎没有用,因为今天有许多用于缓存文件或路径和url的方法,这样可以避免在很多情况下每次调用资源时都必须发出请求(通常由它们的顺序排序)。大数据案例中的流行度排名)。
最后但并非最不重要的一点是,许多Web和移动平台应用程序(我认为是Slack,Discord,Facebook,Twitter ...)每天存储大量媒体文件,这些文件通常与帐户用户相关联,包括公共文件和机密文件,以及信息,为它们每个生成唯一的哈希。
Twitter正在使用自己的唯一标识符字符串(64位BIGINT
)生成器,称为Twitter Snowflake,您可能也很感兴趣阅读它。它基于UNIX纪元值,根据定义,该纪元值在每个毫秒刻度上都是唯一的。
目前还没有一种适用于所有事物的全球性完美解决方案,但是我希望这会对您有所帮助,因为您可能希望对此有更深入的了解,并为要存储的每种上下文和实体找到“最佳解决方案”和链接文件。
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句