0

アイデアは次のとおりです。それぞれが一定量の名前と値のペアを含む、何千ものクエリを受け取ることを期待しています。これらは連想配列として開始されるため、データに何が起こるかをかなり適切に制御できます。これらのNVPは、ソースによって異なります。たとえば、ソースが「A」の場合、配列を受け取ることができます（説明を簡単にするためにJSONで）：{'Key1':'test1','key2':'test2'}しかし、ソースが「B」の場合{'DifferentKey1':'test1','DifferentKey2':'test2'}、データベースに保存するキーを選択していることを受け取ることができます。 、したがって、この場合DifferentKey1、ソースBの配列から選択し、残りを破棄することしかできませんでした。

ここでの私の主な問題は、これらの配列は技術的には完全に無関係なコンテンツである可能性があるということです。それらは非常に一般的な関連性を持っています（両方とも統計を含む配列です）が、それらは非常に異なります（ソースが異なる、つまり異なるゲーム/スポーツであるという点で）。

私はSQLを考えていました。ゲームとそれぞれのIDで満たされたテーブルを格納することは、一般的なNVP文字列をリンクするための良い方法です。例えば：

Games table:
| id | name |
-------------
  1    golf
  2    soccer

NVP table
| id | game_id | nvp
   1      1      team1score=87;team2score=94;team3score=73;
   2      2      team1score=2;team2score=1;extratime=200;numyellowcards=4;

それが十分に明確であることを願っています。でも私が何を言っているのか分かりますか？使用できるデータの量が不確定な場合、どうすればテーブルを構成できますか？ありがとう。

編集：私は注意する必要があると思います、明らかにこのセットアップはうまくいくでしょう、しかしそれは賢明な最高のパフォーマンスですか？そうでないかもしれない？よくわかりません。皆さんが思いつくことができるものを見てみましょう。

4

2 に答える 2

0

SQLデータベースは、高度なリレーショナルデータに最適ですが、データがリレーショナルではなく、固定スキーマがないこのような場合は、NoSQLソリューションを使用する方がよい場合があります。たくさんありますが、私はそれらを十分に使用していないので、何が最適かを確認できません。データがRAMに収まる場合は、redisが最適です。

于 2012-06-13T01:46:40.983 に答える
0

リレーショナル データベースに名前と値のペアを格納する一般的な方法は、「エンティティ/属性/値」として知られています。Stack Overflowで多くの議論が行われています。

それはすべて、アプリケーションがデータで何をしたいかによって異なります。保存は簡単ですが、クエリははるかに困難です。

スポーツ アプリケーションを構築している場合は、サポートしたいドメイン コンセプトがある可能性があります。たとえば、サッカーの場合は、プレイした試合に基づいてリーグの順位を表示します。ゴルフの場合は、バーディーまたはイーグルの数を表示します。特定のチーム/プレーヤーがシーズン中にプレイしたすべてのゲームを表示したい場合があります。

リレーショナル データベースで簡単に構築できるものもあれば、巨大なデータ セットに対して驚くべきパフォーマンスを発揮するものもあります。これまでで最高得点のゲームを見つけ、1998 シーズンの最後のゲームを見つけ、プレーヤー x が登場するすべてのゲームを見つけます。これらのドメインの概念を表すスキーマを構築できる限り、すべてがうまく適合します。

あなたが書いていることからすると、固定数のスポーツがあるように聞こえます。システムに入ってくるデータは特に構造化されていないように思えますが、それをドメイン モデルに構造化できるはずです。そうであれば、各スポーツのドメイン ロジックを反映するリレーショナル スキーマを構築することをお勧めします。

そうでない場合 (事前にドメインについて推論できない場合) は、リレーショナル モデルは適しておらず、おそらく NoSQL の方が適しています。しかし、同じ問題に遭遇するでしょう - 名前と値のペアから意味を抽出するのは難しいでしょう!

于 2017-08-21T13:32:40.217 に答える