Database design 持久化大文本字段

冒着听起来愚蠢的风险，在需要持久化大数据字段（例如博客帖子）的场景中，数据库存储始终是最佳解决方案吗

我猜数据库膨胀的风险可能不会太高，因为这就是数据库应该擅长的，对吗？此外，数据库还可以用于文本索引和快速访问。这个假设正确吗

---

我突然想到，这种数据可以存储在数据库之外的某种xml平面文件中，我不确定这是一个好主意…

数据库比xml平面文件保存为文本要好得多。

---

它还具有处理并发性和事务的优点。

在数据库中存储文本，包括博客帖子之类的内容，是经常做的事情。有数据库来处理这个问题

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

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

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

---

给你一个真实而具体的例子，StackOverflow搜索是使用SQL Server全文搜索实现的，许多人批评它与使用Google的“site:StackOverflow.com…”（默认情况下我经常使用它）相比效率低下。

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

您的假设是正确的。您确实不想将该文本存储在数据库之外，因为您将丢失：

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

此外，尽管在图像（）方面有一个类似的主题被打死了，但文本并没有引起同样的关注，因为“大”文本实际上非常小（10KB或100KB是一个巨大的上限），而且大多数数据库都有一个特殊的数据类型来存储文本。对于图像，有争论的地方，因为我们将讨论（数）兆字节范围内的数据

---

cletus提出了有趣的考虑，最相关的IMO是数据库全文引擎的性能通常比专用搜索引擎（如Lucene和friends）差。这必须根据潜在问题和数据的实际使用情况来考虑。此外，有些数据库搜索模块的性能比其他模块更好，因此必须在您的特定场景中进行测试。

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

在某种程度上取决于RDBMS

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

---

Ref:

但是你做了什么基准测试？你是如何避免一致性问题的？我没有，MS Research：