我有一个数据库表，表的主键是自动增加的ID。
对于这个表的每条记录，我最多可以有3个文件，这些文件可以是公开的，所以随机生成文件名不是必须的，这些文件是可选的。
我想我有2种可能的解决方案。
把随机生成的文件名存储在3个可空的varchar列里 然后把所有的文件都存储在同一个地方。
uploadsa1.jpg
属于记录与 uploads/a/1.jpg的文件，并且是一个类型为 ID 1. 但我必须检查文件是否存在，因为文件是可选的。a你觉得这一切有什么好的做法吗？或者说，也许有更好的方法？
为了提高敏感数据的安全性和完全不透明性，比如针对具体的情况，我们可以采用以下方法
我认为明智的做法是确保绝对没有人能够猜到与用户或任何其他实体相关联的文件的数量（因为在这个例子中，我们可以想象到可能还有其他可访问的文件--1.pdf和2.pdf）。根据设计，我们通常希望在一个明确定义的特定情况和上下文中提供对文件的访问。然而，对于一个打算让每个人都能看到的图像文件（例如，一张个人资料照片）来说，情况可能并非如此。这就是为什么上下文在某种程度上很重要。uploads/users/7/invoices/3.pdf如果您选择保留自动增加的标识符作为名称来引用您的文件，这也可以提供有关存储在数据库中的数据大小的信息 (
告知您的服务器上可能已经有127张发票了），并有可能促使不法分子试图获取那些不应该从定义的上下文中获取的资源。如果你选择使用某种独特的生成标识符（GUID），这种情况可能不那么明显。/uploads/invoices/128.pdf我建议你阅读
本文 关于生成(G)(U)UIDs(128位十六进制数字)，为每个上传或创建的文件存储在你的数据库中。如果你使用最新版本的MySQL，甚至可以将这个标识符存放在一个叫 "G"(U)UID的数据库中。 类型，它提供了一个自动转换为UUID的功能，我让你读到了 binary (16)这个有趣的话题 与我所说的相关联。它可能会将此输出为 这是一个更好的方法，只要你确保生成的标识符是唯一的哈希。/uploads/invoices/b0016303-8e4f-487a-8c30-5dddf1ebf7e9.pdf我觉得在这里讨论性能问题没有什么用，因为现在有很多缓存文件、路径和URL的方法，在很多资源被调用的情况下，可以避免每次都要提出请求（在大数据的情况下，通常是按照受欢迎程度排序）。
最后，但并非最不重要的是，许多网络和移动平台应用（我想到了Slack、Discord、Facebook、Twitter......）每天都会存储大量的媒体文件，这些文件往往与账户用户相关联，无论是公开的还是机密的文件和信息，都会为每个文件生成一个唯一的哈希值。
Twitter使用的是自己独特的标识符字符串（64位的）。
)生成器，称为 BIGINT微博雪花 你可能也会感兴趣。它是基于UNIX的纪元值，根据定义，纪元值在每一毫秒的刻度上都是唯一的。没有一个全局性的完美解决方案可以适用于所有的事情，但我希望这能帮助你，因为你可能会想更深入地研究这个问题，并为你要存储和链接文件的每个上下文和实体找到 "最佳解决方案"。