我正在努力决定是否应该在即将进行的项目中使用 MySQL blob 字段类型。
我的基本要求是，可以查看某些数据库记录，并上传多个文件并将其“附加”到这些记录。根据具体情况，查看所述记录可能仅限于某些人。任何类型的文件都可以上传，几乎没有任何限制。
因此，从一种角度来看，如果我选择 MySQL 路线，我不必担心病毒的蔓延或随机 php 文件被上传并以某种方式执行。我还有一个更简单的途径来获得许可并将数据与记录紧密结合。
另一个明显的途径是将数据存储在 webroot 之外的特定文件夹结构中。在这种情况下，我必须为文件夹/文件制定一个特殊的命名约定，以跟踪它们在数据库中引用的内容。
使用 MySQL blob 字段类型是否会影响性能？我担心选择的解决方案会阻碍网站未来的发展以及选择不易维护的解决方案。
使用 MySQL blob 字段类型是否会影响性能？
本质上不是这样，但是如果您有大的 BLOB 堵塞了表和内存缓存，那么肯定会导致性能下降。
另一个明显的途径是将数据存储在 webroot 之外的特定文件夹结构中。在这种情况下，我必须为文件夹/文件制定一个特殊的命名约定，以跟踪它们在数据库中引用的内容。
是的，这是一种常见的方法。您通常会做类似的事情，例如以与它们关联的每个表命名文件夹，其中包含仅基于主键（理想情况下是整数；当然绝不是用户提交的任何内容）的文件名。
这是一个更好的主意吗？这取决于。仅拥有一个数据存储具有部署简单性的优点，并且不必担心向 Web 用户提供对任何内容的写访问权限。此外，如果可能有多个应用程序副本正在运行（例如主动-主动负载平衡），那么您需要同步存储，这对于数据库来说比使用文件系统要容易得多。
如果您确实使用文件系统而不是 blob，那么问题是，您是否通过将别名指向文件夹来让 Web 服务器为其提供服务？
- + 超级快
- + 缓存良好
- - 额外的服务器配置：虚拟目录；需要适当的文件扩展名才能返回所需的
Content-Type
- - 额外的服务器配置：需要添加
Content-Disposition: attachment/X-Content-Type-Options作为反 XSS 措施的一部分，阻止 IE 嗅探 HTML 的标头
或者您是否通过让服务器端脚本将其吐出来手动提供该文件，就像您必须从 MySQL blob 提供服务一样？
- - 可能很慢
- - 需要大量手动 If-Modified-Since 和 ETag 处理才能正确缓存
- + 可以使用应用程序自己的访问控制方法
- + 轻松从服务脚本添加正确的 Content-Type 和 Content-Disposition 标头
这是一种权衡，没有一个全球公认的答案。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
