处理大量冗长的文本字段答案

【问题标题】：Handling numerous lengthy text fields处理大量冗长的文本字段
【发布时间】：2012-12-26 14:23:30
【问题描述】：

我正在设计一个 SQL Server 数据库，它需要有很多 （大约 15 个） 长 varchar 字段，其中大部分我想分配至少 的长度1024 或 2048。由于这显然会远远超出 8060 的页面大小，因此我意识到无论何时访问此表，数据库都可能会受到很大的性能影响。

我还考虑将这些叙述分组到相似的主题中并制作 3 或 4 个单独的表格，或者只创建一个带有 varchar(max) 字段和代表叙述类型的 int 的表格：

create table Narrative
(
  narrative varchar(max),
  narrativeType int
)

原始设计是否会对性能产生重大影响？
在处理大文本字段时可以使用哪些类型的最佳实践？

【问题讨论】：

标签： sql-server-2008 database-design varchar page-size

【解决方案1】：

我不认为我的答案是该主题的最终决定。也许其他人可以对此进行补充。

您将无法在 VARCHAR(MAX) 列上构建聚集或非聚集索引，因为它的大小。这将使您的桌子上的搜索变得非常缓慢。但是，您将能够使用Full Text Search，这将显着提高性能。

就个人而言，如果可以避免的话，我不会将数据拆分到多个表中。这样做的原因是它使查询同质数据变得很麻烦。

在Full Text Search\Indexing 的情况下，如果您的文本使用多种语言（FTS 取决于语言），您可能会想创建多个表。我通过在我的桌子上创建多个Indexed Views 并在我的Indexed Views 上构建全文索引来解决这个问题

如果您期待大量数据，您可能需要考虑Partitions

最好阅读有关主题的更多信息，然后进一步完善您的问题。

【讨论】：

【解决方案2】：

我决定继续将这些叙述拆分到它们自己的表中，并与主表保持 1:1 的关系。我不怀疑我会查询这些varchar 字段中的值，并且不需要对它们进行任何索引。此外，与原始表中的任何其他字段相比，它们的访问频率要低得多，因此将它们拉到单独的表中有助于集中数据库设计，甚至可以提高性能，因为只有在绝对必要时才需要处理它们.

【讨论】：