0

私を完全に混乱させる何かがあり、これほど多くのデータをデータベースに保存する方法がわかりません。以下では、データベースに保存する必要があると思われるものと、そのデータを (効率的に保存するために) どのように使用する予定なのかを正確に説明します。

そして。グリッド上に約 40 のポイントがあります。それらを「オブジェクト」と呼びます。それらには、座標 (x,y)、ID、数、リソース、その他の多くのオブジェクト、およびグリッド上のそのポイントを「防御」する量など、関連する情報があります。ポイントを守れるユニットは100種類以上。これらのユニットは、任意の数のプレイヤーが所有できます。ID と番号は簡単に相互に導出できます (したがって、両方を保存する必要はありません)。

私がしなければならないことは、これらのポイントをスキャンするたびに、これらの情報をすべて保存することです。次に、この情報をデータベースから取り出して、時間の経過に伴うプレーヤーのユニットのグラフを作成し、増加しているか減少しているかを確認する必要があります。また、オブジェクトの総防御力を経時的にプロットして、全体的な変化を追跡したいと思います。

これらのオブジェクトをスキャンする頻度はさまざまで、多くても 1 分間に 1 回です。このすべての情報をデータベースに保存する方法が思いつきません。

どんな助けでも大歓迎です!必要なすべての質問をしてください.. テキストの壁だと思いますが、読んでください!

編集:グリッド上のオブジェクトの数はいつでも変更できます。1つ得ることも、1つ失うこともできます。

4

1 に答える 1

1

出発点は、Entity Relationship Modeling を実際に理解することです。あなたの要件はあなたにとって非常にユニークに見えますが、エンティティ関係モデルに関しては、それらは古い帽子です。基本的には、重要なオブジェクト間の関係のタイプがすべてです。一対一、一対多、多対多の関係について学びます。エンティティ モデルは出発点であり、一部のツールでは、エンティティ モデルからテーブルを生成することさえできます。特定の関係がリレーショナル データベース モデルにどのように変換されるかを理解したら、次のステップに進みます。たとえば、あるチームには多くの野球選手がいます。したがって、これは 1 対多の関係です。これを取得すると、テーブルに外部キーが必要な理由や、行ごとに一意の ID などが必要な理由を理解するのがずっと簡単になります。

もう 1 つのアプローチは、たとえば UML を使用して、最初にオブジェクト モデルを設計することです。それでも、データベース設計にも変換される関係、継承、構成などについてです。しかし、データベースから離れて設計したい場合は、エンティティ関係モデリングが最適です。

于 2012-07-24T20:00:16.223 に答える