私の経験では、これは保存されているデータに大きく依存します。どちらの方法にも長所と短所があります。 MMORPG の場合 次に、ウェブゲームは、PC を持っていると言います。 それはベルトを持っています。また、PCは戦闘中にすばやくアクセスできるように、そのベルトにポーションを入れることができます。そこで、キャラクターのベルトに保存されているポーションのIDを保存します。
最も一般的なリクエストは、「キャラクターXが持っているすべてのポーションを入手する」です。そして、それはどちらの場合もかなり速く実行されます。
これらのポーションIDを別のテーブルとして保存する利点：
- 特定のポーションIDを検索でき、非常に高速です。 ゲーム内の例：管理者がゲームからポーションを削除したため、全員のベルトを更新する必要があります
- あなたはいくつかの素晴らしい統計を得ることができます。 ゲーム内の例：すべてのプレーヤーの中で最も使用されているポーションを探す
- データベースはデータの整合性を維持します。 ゲーム内の例：ポーションを使用したときに、ゲームに「おっと、そのIDのポーションは存在しません」と表示される状況は発生しません。
- 一貫性を保つのに適しています。 ゲーム内の例：ベルトからポーションを取り出し、バックパックに入れました。ゲームは、2つの単純な明確なSQLステートメントを使用してトランザクションを呼び出すことで実装できます。
- JOINを実行できます。 ゲーム内の例：別のテーブルに保存されている名前、重さ、画像とともに、ベルト内のポーションのリストを取得する必要があります。
- ベルト全体を更新しなくても、1つのアイテムを更新できます。 ゲーム内強制例：ベルトに100万個のポーションがあり、1個飲んだ。
jsonとして保存する利点：
- クライアント側でJavaScriptを使用するブラウザゲームの場合、Select-queryを実行してからjsonに変換する代わりに、1つの簡単なリクエストでBeltjsonオブジェクトを取得します
- json配列はすでに順序付けられているため、アイテムの順序を維持する方がはるかに簡単です。テーブルアプローチでは、「順序」と呼ばれる追加の列が必要になり、毎回更新して、2つのアイテムの順序が同じでないかどうかを確認します。
- クライアント側のベルトで一連の再配置を実行してから、[適用]をクリックします—ブーム。1つのクエリでベルト全体を更新できます。一方、テーブルアプローチでは、そのために少なくとも2つのクエリが必要になります（DELETE + INSERT）
- さらに、人気のあるDBMSにはプラグイン があります。 データベース内のjson関数をサポートする
結論：それらはメジャーではありません 利点であり、重要ではありません 問題。それらはすべて解決可能であり、アプリケーションを適切に設計すれば、どちらのソリューションも問題なく機能します。データの保存方法を決定する前に、これらのデータの最も一般的な使用例を自問し、後で解決策を選択してください。