我公司的客户之一，决定他想在SQL（最可能是MySQL）数据库中存储文件。 据我所知，这是可能的，只是通过存储二进制文件或内含的文件。 但那不是问题。
主要模式是将网页存储在一个服务器和数据库中，并将另一个OR网页中的file upload到另一个服务器数据库中，并将其上传到数据库中。 以下的解决scheme是我们怀疑的。
主要原因是安全。 在这种情况下你能提供什么最好的安全解决scheme？ 我担心，通过打破SQL服务器他们得到的文件，因为SQL注入中断比服务器更常见，更多的服务器在公司内部只有真正安全的连接，更多的如果SQL Server崩溃将是痛苦屁股恢复一切，因为sql dump会重一吨。
我正在为这种情况询问争论和其他解决办法。
将文件存储在数据库中意味着添加自定义代码来处理对文件的访问。 虽然这提供了实现底层操作系统不直接支持的复杂安全模型的机会，但是添加的代码越多，注入漏洞的可能性就越大，这会损害数据的安全性/完整性。
虽然我必须承认，我不是SQL Server的专家（但是我知道一些关于mysql的知识），但是这种方法要求代码在数据域内以超级用户的特权执行; 不像一般的文件访问，没有特权分离。 所以如果这个系统受到威胁，那么这个系统是完全受损的。 与操作系统用户帐户被泄露的情况不同，暴露量大大降低。 比较这一点与Microsoft平台上的病毒相比，Unix平台上的问题 – 为Unix编写病毒并不难 – 但直到最近，大多数Microsoft系统不需要特权分离。
服务器在公司内部只有真正安全的连接
不是一个很大的优势 – 查看数据妥协的统计数据 – 大多数都是内部的。
这将是屁股恢复一切的痛苦，因为sql dump会重一吨
诚然，尽pipe在数据库上执行分区/增量备份比在文件系统上执行分区/增量备份容易得多，但是这又意味着增加更多的代码=增加更多的错误。 最大的问题是这是一种非标准的工作方式。 虽然您可以放心，一名初级员工可以使用文件系统备份打开灾难恢复站点，并且可以轻松恢复数据，但是对应用程序备份也是如此。 当然，在select用于自动访问文件的工具（备份，防病毒扫描，重复数据删除，归档…）时，您的select受到了更多的限制。
另外，通过HTTP传递文件，你已经失去了对文件的所有并发控制。
另一个需要考虑的就是，当然对于mysql来说，一旦一个表超出了单个磁盘上的空间，增加更多的容量并不是微不足道的。
其中一些效果可以通过在文件系统上保留文件来缓解，但是通过提供基于networking的前端。 如果你做得对，那么你仍然可以使用权限分离（通过运行web服务器作为浏览器和每个用户/会话之间的代理，处理以经过authentication的用户的权限运行的实际I / O）。 但是，你仍然失去了并发控制，还有其他types的漏洞可以被利用。
作为一家IT服务公司，它是从客户那里获取资金的好方法 – 向他们出售一些他们不需要的东西，让他们使用它存储他们的关键资产，然后为他们提供支持。 但从客户的angular度来看，这是一个非常糟糕的主意。