在SQL数据库中存储大量文本(例如html页面)是个好主意吗?或者将它作为html文件存储在文件系统中是一个更好的主意吗?
图像也是如此 - 将图像数据存储在数据库中或更好地将它们放在磁盘上是一个好主意吗?
例如,存储大量数据会导致性能问题吗?每种存储方法的优缺点是什么?
就数据的大小而言,在这种情况下,我正在查看HTML的“几页”区域和大小小于500kb的图像(尽管可能要小很多)。足以产生您的平均文章/博客条目/等比例网页。
答案 0 :(得分:7)
在数据库中存储二进制数据(文档,图像等)有一些优点。
您可以在与要存储的有关文档的信息(名称,日期等)相同的事务中提交文档本身的更新。这意味着您不必担心编写自己的两阶段提交(尽管ISTR SQL Server 2008有此解决方案)。
您可以立即备份整批文档(元数据),而无需担心必须将数据库与文件系统同步
您可以非常简单地通过.NET Web服务提供文档,因为它们直接进入DataTables,只需将DataTables放入DataSet并传递它就可以毫不费力地进行序列化。
您可以将数据库安全性应用于对象,以及其他数据,而不必担心网络文件权限。
它也有一些缺点:
备份可能会变得非常大
数据库中二进制对象的大小可能比它最初来自的文件大得多,因此在客户端 - 服务器环境中,它可以增加在网络中打开它们所需的时间
根据应用程序的不同,如果必须提供大量大型文档,则可能需要考虑数据库服务器上的负载。
所有这些都说,这是我广泛使用的一种技术,而且效果非常好。
答案 1 :(得分:2)
你投入的越多,你移动的越多,你创造的开销就越大。
如果您有一个出色的Web服务器,那么当您可以将所有这些压力委托给Web服务器时,没有必要将所有额外压力添加到数据库中。
即使从维护的角度来看,在一个漂亮的逻辑结构中移动并使用文件更容易,而不是继续使用数据库。
答案 2 :(得分:1)
这是一个大小问题。这取决于你的图像/文本有多大。
将这些值存储在数据库中与基于文件系统的方法相比具有许多优势,但在某些时候它会变得效率低下。例如,我不会在数据库中存储极高分辨率的图像。
所以这是一个程度问题,反过来,这意味着答案取决于您的硬件资源和系统的架构。所以我不相信你的问题有一个正确的答案。也许您可以告诉我们更多关于您要存储的内容以及服务器外观的详细信息。
答案 3 :(得分:1)
我认为你可以争论任何一方,但我在大量文本方面下来就可以了(因此可以搜索),但是图像应该作为单独的文件存储在数据库中。我从来没有想出任何令人信服的理由将图像存储在数据库中,即使它可能存在。
答案 4 :(得分:1)
要考虑的其他事情是这些大块文本和图像的变化频率。对数据的更改是导致碎片化的原因。碎片可能发生在数据文件和数据库结构中。文件系统比数据库更适合处理碎片。文件更改的频率越高,系统就会越快碎片化。
答案 5 :(得分:1)
将文本存储到数据库中
是的,你应该尽可能多地将HTML内容存储到数据库中=>它简化了备份。您应该使用模板系统,这样您就不会将整个网页结构与每个文档一起存储,只需将不同页面的内容存储到数据库中。
在实践中,我们部署的大多数网站不超过10MB的文本内容(我们使用自己的自定义模板系统)。 10MB的纯文本是很多内容(信不信由你)
将图片存储在文件系统
通常,将图像存储在数据库中是一个坏主意,因为您无法使用FTP快速交换照片。
这种方式维护也会更容易。在网站的生命周期中,徽标,文章照片和支持图形会发生很大变化。与文本不同,您无法将照片的二进制数据完全剪切粘贴到数据库编辑器中....
此外,如果您的数据库损坏 - 这种情况经常发生,那么如果您将图像存储在数据库中,则会遇到麻烦。而文件系统损坏只会影响有限数量的文件。数据库损坏会向您发送提取备份,这是一个时间傻瓜。
答案 6 :(得分:0)
当我以前编程PHP时,这是我的困境之一。在数据库中存储像blob这样的图像可以更容易地管理安全性和权限,但这样做成本很高。
我总是习惯在数据库上存储一些元数据,在文件系统上存储二进制内容。对图像的访问不是直接的(<img src="image/path" />
),而是由PHP脚本提供的,这些脚本在显示图像(<img src="showimage.php?id=$id" />
)之前通过会话检查用户身份验证和授权。我建议你这样做(无论你在做什么样的应用程序)。