1

かなりの数(約 15)の長いフィールドを持つ必要がある SQL Server データベースを設計していますvarchar。そのほとんどは、少なくとも1024 または 2048の長さを割り当てたいと考えています。これは明らかに8060のページサイズをはるかに超えるため、このテーブルにアクセスするたびにデータベースのパフォーマンスが大幅に低下する可能性があることに気付きました。

また、これらの物語を同様の主題にグループ化し、3 つまたは 4 つの個別のテーブルvarchar(max)を作成するか、フィールドとint物語のタイプを表すを含む単一のテーブルを作成することも検討しました。

create table Narrative
(
  narrative varchar(max),
  narrativeType int
)
  1. 元の設計ではパフォーマンスに重大な影響がありますか?
  2. 大きなテキスト フィールドを処理する場合、どのような種類のベスト プラクティスを使用できますか?
4

2 に答える 2

1

私は自分の答えがこの件に関する最終的な言葉であるとは主張しません。おそらく、他の人がこれに追加することができます。

VARCHAR(MAX)サイズが大きいため、列にクラスター化インデックスまたは非クラスター化インデックスを構築することはできません。これにより、テーブルの検索が非常に遅くなります。ただし、パフォーマンスが大幅に向上する全文検索を使用できるようになります。

個人的には、避けられるのであれば、データを複数のテーブルに分割することはしません。その理由は、同種のデータのクエリが面倒になるためです。

の場合Full Text Search\Indexing、テキストが複数の言語である場合、複数のテーブルを作成したくなるかもしれません (FTS は言語に依存します)。Indexed Viewsテーブルに複数を作成し、全文インデックスを構築することで、この問題を回避しました。Indexed Views

大量のデータが予想される場合は、パーティションを検討することをお勧めします

トピックについてもっと読んでから、質問をさらに絞り込むのがおそらく最善でしょう。

于 2013-01-12T05:38:16.300 に答える
0

私は先に進んで、これらの物語をプライマリテーブルと1：1の関係で独自のテーブルに分割することにしました。これらのフィールドの値をクエリすることはないと思います。また、これらのvarcharフィールドでインデックスを作成する必要はありません。さらに、元のテーブルの他のどのフィールドよりもアクセス頻度がはるかに低いため、それらを別のテーブルにプルすると、データベース設計に集中でき、絶対に必要な場合にのみ処理する必要があるため、パフォーマンスが向上する可能性があります。 。

于 2013-01-18T16:25:04.327 に答える