3

ゲームから統計を収集するアプリケーションを構築しています。基本的に、各行がゲーム イベントであるログを解析します。約 50 の異なる種類のイベントがありますが、それらの多くは関連しています。各イベントには特定の値のセットが関連付けられており、関連するイベントはこれらの属性の多くを共有しています。全体で約 50 の属性がありますが、特定のイベントには約 5 ～ 10 の属性しかありません。

バックエンドに Rails を使用したいと考えています。ほとんどのクエリはイベント タイプに関連します。つまり、特定のラウンドで 2 つのイベント タイプが互いにどのように関連するかについては特に気にしませんが、多くのラウンドで 1 つのイベント タイプからのデータを気にするだけです。どのようなスキーマを構築し、どのようなデータベースを使用する必要がありますか?

リレーショナル データベースが与えられた場合、次のことを考えました。

  1. いくつかのテーブルしかないフラットな構造を持ちますが、イベント テーブルには、イベント属性全体と同じ数の列があります。これにより、すべての行に多くの null が発生しますが、必要なものに簡単にアクセスできます。

  2. とりわけ、イベントの種類ごとに表を作成します。これにより、スペースを節約し、パフォーマンスを向上させることができますが、イベントが実際には個別の「アイデア」ではないことを考えると、それほど多くのテーブルを持つのは過剰に思えます。

  3. 関連するイベントをグループ化して、テーブルの数とテーブルごとの属性の数の両方を最小限に抑えます。問題はグループ化になります。これは明確には程遠いものであり、イベントのスーパータイプを適切に確立するには長い時間がかかる可能性があります。また、かなりの量の nil があるという問題を完全に解決するわけではありません。

また、MongoDB などの NoSQL データベースの使用を検討するよう提案されました。この場合には非常に当てはまるように思えますが、私はこれまで非リレーショナル データベースを使用したことがありません。それぞれのテーブルはありませんが、まだ多くの異なるモデルが必要なようです。

何か案は？

4

1 に答える 1

1

これは、MongoDB の優れた使用例のように思えますが、リレーショナル データベースには非常に適していません。

このデータに対して作成するクエリの種類は、最適なスキーマ設計の鍵となりますが、(上記の 1. と同様の単一のコレクション内の) ドキュメントが次のようになっていると想像してください。

{  "round" : 1,
   "eventType": "et1",
   "attributeName": "attributeValue",
   ...
}

ラウンドごと、eventType ごと、すべての属性または指定されたサブセットのみを取得するなど、簡単にクエリを実行できます。

いくつの属性を持つ可能性があるか、どの属性がどのイベント タイプに属しているか、さらにはいくつのイベント タイプがあるかを事前に知る必要はありません。プロトタイプ/アプリケーションを構築すると、必要に応じてモデルを進化させることができます。

非常に大規模な Rails/MongoDB 関係者の活発なコミュニティがあり、多くの開発者に質問をしたり、例として参照できる多くのコードを見つけることができる可能性が高くなります。

試してみて、フィット感が良いかどうかを確認することをお勧めします。開始するのに役立つリンクをいくつか追加するつもりでしたが、選択するには多すぎます。オブジェクト マッパーを使用するかどうかについて質問があるかもしれないので、ここにそれに対する適切な回答を示します。

Ruby と MongoDB を使用した動的属性の処理に関する優れた記事は、こちらです。

于 2012-06-02T03:07:10.727 に答える