2

私は現在、データを取得し、ユーザー定義の制限に基づいて生成されたシナリオを整理する必要がある作業の問題に取り組んでいます。私は多くのことを試しましたが、私が望むほど効率的に何かを実行することはできないようです. 実行をスケーリングできるように、DB の外部で実行する必要があるかもしれませんが、可能であれば DB の内部で実行する必要があると考えました。たとえば、3 つのエンティティがある場合:

Transportation Type:
Car
Boat
Plane

Color:
Blue
Green
Red
Purple
White

Accessories:
Trailer
Wheels
Propeller
Parachute

ユーザーは制限を入力できます:

Transportation_Type=Boat, Accessories= Wheels

そのため、ボートと車輪を含むシナリオの組み合わせは制限されます。

Example Valid Scenario with restriction: Boat/Red/Trailer

したがって、これが複雑になるのは、ユーザー定義の制限があっても、3 つのエンティティに対して考えられるすべてのシナリオを構築すると、それほど悪くはないと想像できることです。しかし、エンティティが 22 個ほどある場合はどうなるでしょうか (エンティティは基本的に値を持つレベルです)。これが巨大になり、制限を適用するのが難しくなることは容易に想像できます。特に、制限を構成するレベル/値 (ボートやホイールなど) のセットである場合。

誰にも考えはありますか？

派生シナリオをチェックできる動的な like ステートメントを作成することで、約 14 ～ 16 レベルで実際にパフォーマンスを向上させることができました。しかし、その後、プロセス時間は爆発的に増加します (レベルにもっと多くの値がある場合、より低いレベルで発生する可能性があります)。

4

2 に答える 2

1

私の理解が正しければ、目標は特定の基準を満たすシナリオを生成することです。シナリオは、属性の組み合わせから生成されます。

各エンティティが個別のテーブルにあると仮定すると、次のようにクエリを実行できます。

select *
from TransportationType tt cross join
     Color c cross join
     Accessories a
where tt.val in (<accepted transportation types>) and
      c.val in (<accepted colors>) and
      a.val in (<accepted accessories>)

私の理解が正しければ、エンティティの数が増えるにつれて多くのシナリオが生成されます。許容可能なシナリオ (エンティティの組み合わせ) の表がある場合、それは物事を絞り込むのに役立ちます。

エンティティごとに個別のテーブルでこれを示しましたが、サブクエリに置き換えることができます。

from (select *
      from table t
      where t.type = 'TransportationType'
     ) TransportationType cross join
     ...
于 2012-08-10T13:06:48.937 に答える
1

あなたの問題は、「部品表」の問題 (BOM)のように見えます。考えられる有効な各シナリオは、階層化されたシステムとして表すことができます。

            Transportation
                   |
                  Type
                   |
               Accessories
                   |
      Trailer Wheels Propeller Parachute

あなたの質問を読んで、色は制約ではないので、制約ツリーに統合する必要はありません。

SQL Server 2008 は、これらの種類の階層をエンコードするための非常にコンパクトで高速な型、HierarchyId 型を提供します。

HierarchyId を含むルックアップ テーブルを使用すると、制約を簡単に定義し、シナリオの有効性の質問に答えて、対応するシナリオの結果を抽出できます。

HierarchyId を使用した BOM 解決の良い例は、2008 年 9 月の MSDN マガジンで読むことができます。

于 2012-08-10T00:43:58.783 に答える