2

私が顧客に直面しているアプリケーションは、次のようになります。

  • エンドユーザーが「材料」を入力できるようにします。
  • それらの資料には、任意の数の「プロパティ」を追加できます。
  • プロパティには、decimal、int、dateTime、varchar（5文字からテキストの大きなチャンクまでさまざまな長さ）の任意のタイプの値を指定できます。

基本的に、スキーマは次のようになります。

マテリアル
MaterialIDintnot null PK
MaterialName varchar（100）not null

プロパティ
PropertyIDPropertyNamevarchar
（100）

MaterialsProperties
MaterialID
PropertyID
PropertyValue varchar（3000）

アプリケーションの重要な機能は検索機能です。エンドユーザーは次のようなクエリを入力して資料を検索できます。

  • [プロパティ]inspectionDate>[DateTimeValue]
  • [プロパティ]serialNr= 35465488

これが、200万近くのレコードを含むMaterialsPropertiesテーブルでどのように機能するかを推測します。

データベースは、最初はSQL Server 2000で作成され、その後SQLServer2005に移行されました。

どうすればこれをより良くすることができますか？

4

2 に答える 2

1

MaterialsProperties テーブルを typel IntMaterialProperties、CharMaterialProperties、 などに分けることを検討できます。これは次のようになります。

  • データを分割します。
  • 整数 (またはその他の数値) 型のルックアップの潜在的に高速なルックアップを可能にします。
  • 保管コストを削減できる可能性があります。

Typeに列を導入することもできます。これを使用して、クエリを実行するテーブルをProperties決定できます。MaterialPropertiesこの列は、ユーザーの入力が正しいタイプであることを検証するためにも使用でき、特定の「不適切な」入力に対してクエリを実行する必要がなくなります。

于 2009-08-21T08:21:43.650 に答える
0
  1. ユーザーは独自のプロパティ名を入力できるため、すべてのクエリでプロパティ テーブルのスキャンが必要になると思います (この例では、[inspectionDate] のプロパティ ID を見つける必要があります)。プロパティ テーブルが大きい場合、結合にも時間がかかります。プロパティIDを使用して名前を非正規化して保存することで、最適化を試みることができます。これは、MaterialsProperties テーブルの非正規化列になります。
  2. プロパティ タイプ (int、char など) を materialsproperty テーブルに追加し、そのタイプでテーブルを分割してみてください。
  3. クエリの最適化については、オブジェクト リレーショナル マッピング/エンティティ属性値モデルの手法を参照してください。
  4. すでに大量のデータ (200 万レコード) があるため、データ マイニングを行って、多くの材料のプロパティ グループが繰り返されているかどうかを確認します。それらを 1 つのスキーマに配置し、残りを EAV テーブルとして配置できます。詳細はこちらをご覧ください: http://portal.acm.org/citation.cfm?id=509015&dl=GUIDE&coll=GUIDE&CFID=49465839&CFTOKEN=33971901
于 2009-08-21T08:52:12.373 に答える