2

私は、ユーザーが適切なデータを表示するために 4 つのパラメーターを選択する必要があるプログラムに取り組んでいます。これらの各パラメーターには、定義された可能性のリストがあります。現在、これらの各パラメーターには、それぞれ 6、5、3、3 の異なる入力合計があります。計算を行うと、入力の組み合わせが 270 通りあり、その多く (すべてではない) で異なるチャート/グラフをロードする必要があります。さまざまなオプションがあるという点で、amazonやneweggによく似ています。treeview違いは、クエリだけでなくインターフェイス自体が変更されることです。明らかに、各組み合わせを手動で作成することはできません。たとえ 270 で作成できたとしても、最終的に 5 番目のデータセットが追加される可能性があります。

上記のような入力の組み合わせを管理するための設計パターンにはどのようなものがありますか?

編集

明確にするために、入力がA6, B3, の場合C1、それにD2固有のものを動的にロードしたいと思います。

編集

業界固有のものであるため、混乱を招く変数を投入しないように、もう少し一般的なものにしようとしていました。このために4つの新しいものを作ります。

Animals     Age Group    North American Country    Dataview
 Dog          All           Canada                   Historical
 Cat          Teen          U.S.                     Predicted
 etc

したがって、歴史的に米国のすべての年齢層が所有する犬を選択した場合、10 代の犬が所有する傾向の一連のチャートとグラフが表示されるはずです。トレンド。

この例では、国の変更はクエリの変更にすぎませんが、Dataviewまたは「動物」を変更すると、まったく異なるグラフ/チャートのセットが読み込まれる可能性があります。前述のように、後で 5 番目と 6 番目の列が必要になる可能性があるため、それぞれのルックアップでハードコーディングすることは現実的ではありません。また、北米諸国のようにすぐに変更されない国もありますが、変更される可能性がある国もあります。

4

2 に答える 2

1

実際の問題についてはあまり知られていないため、この場合、決定的な答えを出すのは難しく、望ましい結果をもたらす設計パターンについては確信が持てませんが、考えられる解決策に理論的な光を当てます。

シナリオ 1 - アルゴリズムは、数式のように、パラメーター値を指定して結果を計算します。いいえ:

(A6 + B3 + C1 + D2 = "Result 23")    
(A1 + B2 + C3 + D4 = "Result 119")

シナリオ 2 - パラメータは絶対的な結果を形成します。パラメーターが目的の結果に対してハッシュ マップされるハッシュ テーブルまたは他の同様のデータ構造の使用を検討することができます。IE

(A6 + B3 + C1 = d0c423a2 = "Result 1")
(A2 + B5 + C4 = f6d33e56 = "Result 2")
(A3 + B4 + C1 = a34e6bbc = "Result 3")

シナリオ 3 - パラメーターが個別に部分的な結果を返し、それらがまとめて目的の結果セットを返します。ここでも、ハッシュ テーブルを使用できます。IE

(A1 = cd3de456 = "Partial Result 1")
(A3 = d4e5ca23 = "Partial Result 2")
(B3 = b567d342 = "Partial Result 4")
(C1 = a34e6bbc = "Partial Result 66")
(D2 = f6d33e56 = "Partial Result 123")

したがって (A1 + B3 + C1 + D2 = "Partial Result 1", "Partial Result 4", "Partial Result 66", "Partial Result 123")

正しくコーディングされていれば、これらのいずれも理論的には機能し、将来の追加パラメーターの追加に役立つ可能性があります。

于 2012-08-27T21:47:47.810 に答える
1

あなたの最新の編集に基づいて、これは間違いなくデータベースの仕事のように思えるか、それが失敗した場合、linq のようなものを使用してクエリできる構造または構造のセットのように思えます。

私の最後の答えを考えると、これはシナリオ 2 (パラメーターが特定のデータ セットに完全にマップされる) またはシナリオ 3 (パラメーターがそれぞれデータに関連し、収集されたデータをコンパイルして目的の結果にすることができる) のように思われます。 ）。

データベース構造 (下図) に関しては、次のようにコーディングします。

[TABLE  : Parameters]
PK  : ParameterID
    : Parameter1
    : Parameter2
    : Parameter3
    : Parameter4
    : Parameter5
    : Parameter6

[TABLE  : Results]
PK  : ResultID
FK  : ParameterID [related to Parameters.ParameterID]
    : ResultData

これを次のようにクエリできます。

"SELECT ResultData FROM Results WHERE ParameterID = (SELECT ParameterID FROM Parameters WHERE Parameter1 = "" AND Parameter2 = "");

このようにして、パラメータの任意の組み合わせを一意の結果にマッピングできます

別の方法でそれを行うことさえできるかもしれません:

[TABLE  : Results]
PK  : ResultID
    : ParameterHash
    : ResultData [possibility that this relates to other tables holding your results]

これを少し異なる方法で照会できます。

"SELECT ResultData from Results WHERE ParameterHash = '" + ComputeParameterHash(P1, P2, P3, P4, P5, P6); + "'";

このようなデータ構造を使用しても、将来追加される追加パラメーターの影響を受けません。ハッシュを使用してパラメーターを結果に解決する 2 番目のテーブルの例を考えると、任意の量のパラメーターをハッシュ計算機に追加して、データ セットごとに一意のハッシュ値を生成できます。（衝突に注意してください）。最初の例では、より多くのパラメーターを追加すると必然的にテーブルに列が追加されるため、より多くの作業が必要になります。これは既存のレコードには影響しませんが、より多くの作業が必要になります。

結果のデータが複数のテーブルに分散している場合は、ビューを使用して異なるテーブルのデータを連結し、目的の結果を提供することを検討してください。たとえば、パラメーターはビュー内のデータを選択し、ビューを作成する基になるテーブルからデータを取得します。したがって、複数のテーブルからコード レベルでデータを連結することを心配する必要はありません。データベースはそれを行うことができます。

デザイン パターンを使用するという点では、あなたの例を考えると、Entity Frameworks は、リレーショナル データ (データベース内) とオブジェクト指向データ (コード内) の間の関係を維持するのに役立つかもしれません。

これがあなたが探しているものではない場合は申し訳ありませんが、今私が考えることができるのはこれだけです. これはデータベース構造に基づいた抽象的な設計であると考えてください。ただし、他のデータ構造で動作するように変更できます。

于 2012-08-28T15:07:06.673 に答える