0

フィールドのさまざまな組み合わせに対して多くのカウントを提示する必要があるテーブルがあります。これはオンザフライで行うにはかなりの時間がかかり、履歴データは提供されません。そのため、これらのカウントをタイムスタンプとともに別のテーブルに保存する最善の方法を考えています。これにより、それらをすばやくクエリして履歴トレンドを取得できます。カウントごとに、それを識別するために 4 つの情報が必要であり、保存したい約 1000 の異なるメトリックがあります。私は 3 つの異なる戦略を考えています。カウントとタイムスタンプがありますが、取得するカウントを識別する方法は異なります。

  1. カウントを識別するための 4 つのフィールドを持つ 1 つのテーブル。4 つのフィールドは、異なる外部テーブルからのデータが含まれているため、正規化されません。
  2. 1 つの「タグ」フィールドを持つ 1 つのテーブル。4 つの情報がタグとして含まれます。このタグを強化して別のテーブルに保持し、タグ部分ごとにフィールドを持ち、それらを外部テーブルにリンクすることができます。
  3. 1 つまたは複数のフィールドで正規化できるように、カウントのグループごとに異なるテーブルが必要ですが、これには 6 から数十のテーブルが必要になります。

まったく正規化されていない最初のものを使用しますが、このすべてのカウントを保存するためのより良い方法または簡単な方法があるかどうか疑問に思っています。

値のサンプル: status,installed,all,virtual,1234,01/05/2015

  • 最初のフィールド、ステータスには最大 10 個の値を指定できます
  • インストールされた 2 番目のフィールドは、異なるフィールドごとに最大 10 個まで持つことができます 1
  • 3 番目のフィールド all は、最大 10 個の異なる値を持つことができますが、すべてのカテゴリで同じです
  • 4 番目のフィールドである virtual は、最大 30 個の値を持つことができ、以前のすべてのカテゴリでも同じになります。
  • 最後の 2 つのフィールドは数値とタイムスタンプです

ありがとう、アイザック

4

1 に答える 1

1

多くのメトリックがあり、メトリック内計算を行うためにそれらを使用する必要がない場合は、1. ソリューションを使用できます。

多分こんな感じでテーブルを作ると思います

Satus_id | Installed_id | All_id | Virtual_id | Date | Value

または、最初の 4 つの列の組み合わせに適切な名前がある場合は、おそらく 2 つのテーブルを作成します (この可能性を 2 の 2 番目のソリューションと呼んでいると思います)。

Metric Table
Satus_id | Installed_id | All_id | Virtual_id | Metric_id | Metric_Name 

Values Table 
Metric_id | Date | Value

これは、メトリックまたはその他の詳細に名前がある場合に適しています。そうでない場合は、最初のアプローチとの組み合わせごとに複製する必要があります。

どちらの場合も、異なるメトリックを使用して行内操作を行うのは少し複雑になります。このため、このアプローチは高レベルの KPI に対してのみ推奨されます。

最後に、最後の 2 つのフィールドのすべての可能な組み合わせがテーブルに常に存在するため、それらを列に変換することを考えることができます。

Satus_id | Installed_id | Date | All1_Virtual1 | All1_Virtual2 | ... | All10_Virtua30

All に 10 個の値、Virtual に 30 個の値を使用すると、300 列になり、扱いが非常に簡単ではありませんが、次のようなことを行う必要がある場合は価値があります。

(All1_Virtual2 - All5_Virtual23) * All6_Virtual12

しかし、これらの場合、(可能であれば) 事前に計算を行って列の数を減らすことをお勧めします。

于 2015-05-01T11:17:27.343 に答える