持久化大文本字段

Question

冒着听起来很愚蠢的风险，在需要保留大数据字段的情况下（例如博客帖子），数据库存储总是最好的解决方案吗？

我猜测数据库膨胀可能不是太大的风险，因为那些数据库本来就是擅长的，对吧？数据库也可以用于文本索引和快速访问。这个假设是否正确？

我觉得这种数据可以存储在数据库之外的某种xml平面文件中，我不确定这是个好主意......

Answer 1

将文本存储在数据库中，包括博客文章之类的内容，通常都是这样做的。有数据库来处理这个问题。

将大型内容（例如图像，大型文本文件等）存储在数据库外（即文件系统中）并从数据库中引用它们也很常见。这样做可能会限制数据库大小，但会出现其他问题，例如处理并发问题（例如同时编辑文件）。

有很多因素可以确定哪种解决方案最合适，包括编辑频率，文件大小，文件数量等等。

对于文本索引的数据库处理，支持各不相同。 MySQL（使用MyISAM存储）具有全文搜索功能。带有正确插件的SQL Server也有它。与Oracle相同。它可能很有用，但比通用搜索引擎（例如Lucerne）更有限。您的要求和约束将决定数据库索引是否足够，或者您是否需要搜索引擎类型解决方案。

为了给您一个真实而具体的例子，StackOverflow搜索是使用SQL Server全文搜索实现的，并且许多人批评它与使用Google的“site：stackoverflow.com ....”（我使用的）无效默认情况下。）

Answer 2

您的假设是正确的。你真的不想把这个文本存储在数据库之外，因为你会丢失：

• 交易安全
• 搜索功能（可以通过不同的工具添加，带来自己的一组问题/要求）
• 易于维护
• 一致性（如果有人删除xml文件会怎样）

此外，虽然类似的主题在图像方面被打死（should one store images on the DB or in the filesystem?），但文本并没有引起同样的关注，因为“大”文本实际上非常小（10KB或100KB）作为一个巨大的上限），大多数数据库都有一个特殊的数据类型来存储，好吧，文本。有了图像，我们可以讨论（几个）兆字节范围内的数据。

克莱托斯引起了相互关注的考虑，最相关的IMO通常是数据库全文引擎比专用搜索引擎（如Lucene和朋友）表现更差。必须根据潜在问题以及您对数据的实际使用情况来考虑这一点。此外，还有一些数据库搜索模块的性能优于其他模块，因此必须在特定情况下进行测试。

Answer 3

DasBlog使用XML来存储博客条目中的文本，但我知道这有一些扩展问题。

Answer 4

在某种程度上取决于RDBMS。

在SQL Server（2008版之前）中，建议（从基准测试中获得），如果放入数据库小于256K，如果放入文件系统大于1MB（中间有灰色区域）。

参考：To BLOB or Not To BLOB:Large Object Storage in a Database or a Filesystem?

Answer 5

数据库比xml平面文件好得多，可以另存为TEXT。 它还具有处理并发和事务的优点。

Answer 6

如果您完全关注性能和可靠性，则应认真考虑使用符合您要求的数据库。这些系统的开发人员将大量时间用于解决在尝试使用某种平面文件时需要重新解决的所有问题。