0

概要：

ほとんどの場合、製品の分類に使用されるテーブル「category」があり、現在は次のようになっています。

CREATE TABLE [dbo].[Category]
( 
CategoryId int IDENTITY(1,1) NOT NULL, 
CategoryNode hierarchyid NOT NULL UNIQUE,
CategoryString AS CategoryNode.ToString() PERSISTED,
CategoryLevel AS CategoryNode.GetLevel() PERSISTED,
CategoryTitle varchar(50) NOT NULL,
IsActive bit NOT NULL DEFAULT 1
)

このテーブルは、ショッピングWebサイト（通常はすべてのページビュー）にカテゴリ階層を表示するために頻繁に照会され、かなりの数のアイテムを含めることができます。

データレイヤーでEntityFrameworkを使用しています。

質問：

Webページのコンテンツ全体の形で提供される可能性のあるかなり大きな「説明」を追加する必要があります。これを追加するのではなく、関連するテーブルに保存する必要があるかどうか疑問に思っています。エンティティフレームワークが「description」列をデータベースから100％ドラッグする場合、既存のカテゴリテーブルは、99.5％の確率でCategoryTitleとCategoryIdのみが必要になります。

通常、Entity Frameworkのオーバーヘッドについては心配しませんが、その場合は、それを考慮することが重要だと思います。ストアドプロシージャからのビューまたは複合型を使用してこれを回避することもできますが、これは、避けたい多くのリファクタリングを意味します。

このシナリオに関連して、誰かが私の手首を叩いたいという考え、提案、または願望を持っているかどうかを知りたいだけです...

編集：

セカンダリテーブルの設定を躊躇している理由は、Categoryテーブルと1対1の関係にあるテーブルを追加するというアイデアが好きではないためです。これはやや無意味に思えます。しかし、私もDBAではないので、これが許容できる方法であるかどうかはわかりません。

4

2 に答える 2

1

列をテーブルに配置してから、他のすべての列をカバーするインデックスを作成できます。そうすれば、現在のスキーマで行うすべてのルックアップを実行するときにインデックスが使用されます。

この構造のキーワードはCoveringIndexです：http：//en.m.wikipedia.org/wiki/Database_index#Covering_index

于 2012-10-24T13:48:38.493 に答える
0

カテゴリテーブルのレコードのサイズを大きくしないという単純な理由で、別のテーブルに保存します。このようなVARCHAR列によるレコードサイズの増加は、特定のディスクページ（通常はサイズ4KB）に収まるレコード数を減らし、それによって検索するメインメモリにフェッチするページ数を増やし、ディスク数を増やします。アクセス、クエリの実行時間に影響します。

これを別のテーブルに格納し（つまり、カテゴリテーブルを最も頻繁にアクセスされる列とあまり使用されない列に垂直に分割し）、OneToOneアプリケーション層で、あまり使用されないものを含むエンティティとの関係を定義します。列は、メインのカテゴリエンティティのメンバーとして、フェッチタイプをLAZYに設定します。

于 2012-10-24T12:14:33.190 に答える