リレーショナルデータベース内の使用可能な在庫/オブジェクト/アイテム（カタナなど）の複数の「用途」（たとえば武器）をモデル化する方法

したがって、私はwww.ninjawars.netでアイテムの使用を拡大することに取り組んでおり、私たちが使用しているリレーショナルデータベースでそれらを柔軟に表現する方法が正確にわかりません。

私は間違ったツリーを吠えているかもしれないので、他の方向に遠慮なく提案してください。しかし、現在、各アイテムには関係する「タグ」が必要だと思っています。

たとえば、現在、カタナは「アイテム」データベースの行です。それを武器にして保持可能なものにするために、私は「特性」のデータベースと、それらの間を単純にリンクするitem_traitsテーブルがあると考えていました。

// Objects and their basic data

item_id | item
1 | Naginata


// Things that objects can do

trait_id | trait
1 | weapon
2 | holdable

// How those objects do those things, e.g. powerfully, weakly, while on fire

_item_id | _trait_id | item_trait_data
1 | 1 | damage: 5, damage_type: sharp, whatever, etc

結果として生じる追加のデータ（たとえば、剣によるダメージ、damage_typeなど）をモデル化する方法が本当にわかりません。

アイテム全体が複数の場所に保存されることにも特に不満があります。たとえば、「短い剣」のように別の名前のアイテムのコピーを作成するには、以下からコピーする必要があります。重複するアイテムを作成するための複数のテーブル。

私が見逃しているものをレイアウトするより良い方法はありますか？

編集：私はサイトで使用中のpostgresqlデータベースをすでに持っていることに注意すべきです、それが私のデータストレージにそれを使用したい理由です。

編集：私が現在見ている実装の回答を追加しました。

私は皆に少し反対し、ここでは関係的アプローチは合理的であると言います。ここで興味深いのは、アイテムが複数の役割を持つことができることです。主な問題は、このリレーショナルレイアウトとコード内のOOレイアウトの間のマッピングが「自然」に感じられないことですが、データベース側では、複数のロールをきれいに表現できると思います（奇妙なエンコーディングや冗長性なしで、結合のみ） 。

最初に決定することは、どの程度のデータがアイテム固有であり、どの程度が特定のタイプのすべてのアイテムによって共有されるかです。

すべてのデータがアイテム固有である場合は、次のようにします。

// ITEMS table: attributes common to all items
item_id | name        | owner         | location             | sprite_id | ...
1       | Light Saber | 14 (Tchalvek) | 381 (Tchalvek house) | 5663      | ...

// WEAPONS table: attributes for items that are weapons
item_id | damage | damage_type | durability | ...
1       | 5      | sharp       | 13         | ...

// LIGHTING table: attributes for items that serve as lights
item_id | radius   | brightness | duration | ...
1       | 3 meters | 50         | 8 hours  | ...

このデザインでは、すべての（またはほとんどの）アイテムが持つ属性とともに、すべてのアイテムがItemsテーブルにあります。アイテムが実行できる追加の各役割は、個別のテーブルです。

武器として使用したい場合は、武器テーブルで調べます。そこにあれば、武器として使用できます。ない場合は、武器として使用できません。レコードの存在は、それが武器であるかどうかを教えてくれます。そして、そこにある場合、その武器固有の属性はすべてそこに格納されます。これらの属性はエンコードされた形式ではなく直接格納されるため、それらを使用してクエリ/フィルターを実行できます。（たとえば、ゲームのメトリクスページの場合、プレイヤーを武器の損傷タイプ別に集計することができますが、いくつかの結合とgroup-bydamage_typeでそれを行うことができます。）

アイテムは複数の役割を持つことができ、複数の役割固有のテーブルに存在します（この例では、武器と照明の両方）。

「これは保持可能ですか」のようなブール値の場合は、Itemsテーブルに入れます。武器やその他のロールテーブルでルックアップを実行する必要がないように、「これは武器です」などをキャッシュする価値があります。ただし、冗長性が追加されるため、同期を保つように注意する必要があります。

タイプごとにテーブルを追加するというアリの推奨事項も、一部のデータがアイテムごとに変化しない場合は、このアプローチで使用できます。たとえば、武器のダメージがアイテムごとに異なるわけではないが、役割がアイテムごとに異なる場合は、共有されている武器の属性を表にまとめることができます。

// WEAPONS table: attributes for items that are weapons
item_id | durability | weapon_type
1       | 13         | light_saber

// WEAPONTYPES table: attributes for classes of weapons
weapon_type_id | damage | damage_type
light_saber    | 5      | energy

別のアプローチは、アイテムが果たす役割がアイテムによってではなく、アイテムの種類によってのみ変化する場合です。その場合は、item_typeをItemsテーブルに入れ、「武器である」、「保持可能である」、「ライトである」などのプロパティをItemTypesテーブルに格納できます。この例では、アイテム名もアイテムごとに異なるようにします。

// ITEMS table: attributes per item
item_id | item_type    | owner         | location
1       | light_saber  | 14 (Tchalvek) | 381 (Tchalvek house)

// ITEMTYPES table: attributes shared by all items of a type
item_type   | name        | sprite_id | is_holdable | is_weapon | is_light
light_saber | Light Saber | 5663      | true        | true      | true

// WEAPONTYPES table: attributes for item types that are also weapons
item_type   | damage | damage_type
light_saber | 5      | energy

アイテムタイプと武器タイプはゲーム中に変更されない可能性が高いため、これらのテーブルを一度メモリにロードし、データベース結合ではなくハッシュテーブルでそれらの属性を検索できます。

残念ながら、このような状況では、リレーショナルデータベース（SQLなど）が不足し、非リレーショナルデータベース（MongoDBなど）が優れています。とは言っても、リレーショナルデータベースでデータをモデル化することは不可能ではありません。コードベースは既にSQLに依存しているように見えるので、次のモデルを使用します。

アイテムを作成してテーブルを使用する代わりに、アイテムタイプごとにテーブルと「[item] _type」参照テーブルを作成します。

以下にいくつかの例を示します。

weapon_type_id | weapon_type
1 | sharp

weapon_id | weapon| weapon_type_id | damage
1 | Short Sword | 1 | 5

potion_type_id | potion_type
1 | HP
2 | Mana

potion_id | potion| potion_type_id | modifier
1 | Healing Elixer | 1| 5
2 | Mana Drainer | 2| -5

このソリューションは、多くの長期的な柔軟性とスケーラビリティを提供し、無駄なスペースを削減し（排除しないとしても）、自己文書化します（「item_use_data」とは異なります）。それは開発者側でもう少し設定が必要ですが、私の意見では、リレーショナルデータベースを使用してデータを格納する必要がある状況で利用できる最もエレガントなソリューションです。一般的に言えば、非リレーショナルデータベースは、SQLベースのデータベースよりもパフォーマンスが優れているため、データのモデル化の方法に柔軟性があるため、ゲーム開発にとってはるかに優れています。

編集1： potion_type_idフィールドのエラーを修正しました

編集2：追加の視点を提供するために、非リレーショナルデータベースとリレーショナルデータベースの詳細を追加しました

まず、オブジェクト指向の継承アプローチをダンプし、コンポーネントベースのシステムを使います。

これを実行すると、SQLレイアウトが突然はるかに簡単になります。共有ID番号を持つコンポーネントタイプごとに1つのテーブルがあります。アイテム＃17が必要な場合は、すべてのテーブルで「アイテムID 17」を検索します。キーを持つすべてのテーブルには、コンポーネントが追加されます。

アイテムテーブルには、一般的なアイテムに必要なすべてのデータ（名前、販売価格、重量、サイズ、その他すべてのアイテムで共有されるすべてのもの）が含まれます。武器テーブルには、武器に適切なすべてのデータが含まれ、ポーションテーブルには、適切なすべてのデータが含まれますポーションの場合、アーマーテーブルには、アーマーの適切なデータがすべて含まれています。胸当てが欲しい、それはアイテムのエントリーであり、鎧のエントリーです。あなたが飲むことができる剣の兜が欲しい、あなたは各テーブルにエントリーを置くだけで、バム、それで終わりです。

この同じパターンは特にアイテム固有のものではないことに注意してください。これは、クリーチャー、ゾーン、その他の必要なものに使用できます。驚くほど用途が広いです。

SQLの使用は重大な間違いでした。静的なゲームデザインデータの保存には絶対に適していません。

SQLから離れることができない場合は、シリアル化されたfromにアイテムを格納することを検討します。すなわち

item_id (int) | item (BLOB)
1             | <binary data>

もちろん、これは醜く、すべてのSQLの「便利さ」をウィンドウの外に投げ出しますが、実際に必要ですか？おそらく、あなたはとにかくゲーム開始時に、あなたのアイテムデータのすべてを読まないし、決してSELECT以外によりますitem_id。

必要になる可能性のあるトレイトの数に応じて、さまざまなトレイトに対応するさまざまなビットを持つオブジェクトにシンプルなビットマスクを使用できます。

000001 = holdable
000010 = weapon
000100 = breakable
001000 = throwable
010000 = solids container
100000 = liquids container

次に、単純なビットテストを実行して、オブジェクトが特定の関数に使用できるかどうかを確認できます。

したがって、「ガラス瓶」の値は101111で、保持可能で、武器として使用でき、簡単に壊れて、投げたり、液体を入れることができます。

アイテム用に作成したエディターには、オブジェクトの特性を有効/無効にするための簡単な一連のチェックボックスを設定できます。

私たちのプロジェクトでは、アイテムが持つ可能性のあるさまざまな「追加データ」のitem_attributesがあります。次のようにレイアウトされています。

item_id | attribute_id    | attribute_value | order 
1        25 (attackspeed)       50             3    

次に、次のような属性テーブルがあります。

id |   name       | description
1    attackspeed    AttackSpeed:

Ari Patrickは正しいですが、最終的にはリレーショナルデータベースは作成されません。欠点は、新しいアイテムを生成するためのかなり複雑な手順があることです（外部ツールを使用して実行します-これを強くお勧めします。これらを手動で追加しないでください。混乱するだけです）。

もう1つのオプションは、スクリプト言語を使用してアイテムテンプレートを作成することです。そうすると、テンプレートを簡単に解析して、それを使用して新しいアイテムを作成できます。もちろん、アイテムデータをデータベースに保存する必要がありますが、その時点で、新しいアイテムの作成の詳細について心配する必要はありません。古いスクリプトファイルをコピーして、いくつかの情報を変更するだけで十分です。トーゴ。

正直なところ、新しい静的アイテムの作成方法をやり直すとしたら、スクリプトアイテムテンプレートを使用して、はるかに簡単な方法をとるでしょう。

これは典型的な多対多の関係であり、あらゆる有能なリレーショナルデータベースには難解ではありません。1つのオブジェクトに対して多くの特性があり、1つの特性は1つ以上の異なるオブジェクトタイプで使用できます。3つのリレーション（テーブル）をモデル化し、1つは関連リレーションで、これで完了です。適切なインデックス作成により、迅速なデータ読み取りが保証されます。

コードにORMを重ねれば、DBとミドルウェアの間で行き来する問題はほとんどなくなります。多くのORMは、クラス自体も自動生成できるため、さらに「見えない」ようになります。

NoSQLデータベースに関しては、それを実行できない理由はありません。現在のところ、ぼろやブログでそのテクノロジーを応援するのはファッショナブルですが、それらには固有の問題がたくさんあります。複雑な動的読み取りや更新、不十分なサポートツールチェーン、冗長データ、それに伴う整合性の問題などには不十分です。ただし、トランザクション機能とそのオーバーヘッド、および分散/レプリケーションのモデルが簡単なため、スケーラビリティが優れているという魅力があります。 。

リレーショナルデータベースとNoSQLデータベースの通常のホブゴブリンはパフォーマンスです。RDMBSが異なると、オーバーヘッドの度合いも異なるため、FacebookまたはTwitterのレベルにスケーリングするのにあまり好ましくありません。ただし、これらの問題に直面することはほとんどありません。それでも、シンプルなSSDベースのサーバーシステムでは、パフォーマンスに関する議論が無意味になる可能性があります。

明確にしましょう：ほとんどのNoSQLデータベースは基本的に分散されたハッシュテーブルであり、コード内のハッシュテーブルと同じように制限されます。すべてのデータがそのモデルにうまく適合するわけではありません。リレーショナルモデルは、データ間の関係をモデル化するためのはるかに強力です。（交絡因子は、ほとんどのRDBMSが、人気のあるWebの0.0001％、つまりFacebookなどの要求にうまく対応していないレガシーシステムであることです。）

これは、Entity Framework 4とその（CTP）コードファースト機能のように、より現代的なORマッパーが本当に役立つと思う場所です。クラスとその関係を通常のコードで記述するだけで、それらを装飾したり、ツールを手動で実行したりする必要はありません。EFは、必要なリンクテーブルなどを備えたSQL形式のバッキングストアを生成します...創造性を最大限に引き出します^^

これが私が今検討していることです：

とにかく、すべての「特性」は本質的にコードの変更を必要とするため、特性（およびそれらが必要とするデフォルトのデータ）をコード自体（少なくとも今のところ）に保持することにしました。

例えば $traits = array('holdable'=>1, 'weapon'=>1, 'sword'=>array('min_dam'=>1, 'max_dam'=>500));

次に、アイテムはデータベース内の「trait_data」フィールドjson_encode()を取得します。このフィールドは、関数を使用してJSON形式で格納されます。

item_id | item_name | item_identity | traits
1 | Katana | katana | "{"holdable":1,"weapon":1,"sword":{"min_dam":1,"max_dam":1234,"0":{"damage_type":"fire","min_dam":5,"max_dam":50,"type":"thrown","bob":{},"ids":[1,2,3,4,5,6,7]}}}"

計画では、アイテムは親の特性からすべてのデフォルト統計を継承し、デフォルトとして設定された特性との違いを指定するオーバーライド特性のみを持ちます。

トレイトフィールドの欠点は、jsonの部分を手動で編集できることですが...データベースにあるデータを使用して編集するのは簡単でも安全でもありません。

これは少しハックで、私はそれが良いDB設計であることを保証しません。私のDBクラスは少し前のことで、すぐには頭に浮かびません。ただし、たとえばアイテムの数が10未満であることが保証されている場合は、各アイテムにattribute1フィールド、attribute2フィールドなど、最大でattribute10を指定できます。属性の数を制限する代わりに、多対多の項目属性テーブルを使用する必要がなくなります。

振り返ってみると、それはひどいデザインだと思いますが、快適なリレーショナルデータベースを使い続けることができ、未知の領域に行く必要がないことを意味します。トレードオフがそれだけの価値があるかどうかを決めるのはあなた次第です。

Nevermindは良い答えを出しましたが、これのためのデータベースさえ必要ですか？すべてのデータをプレーンファイルに格納し、起動時にプログラムに読み込むことは、これを行う最も賢い方法のようです。

編集：
そうです、ステートレスな要求駆動型の環境では、データをデータベースに保存する方が適切です。データをファイルに書き込み、コードを記述して、Nevermindが提案するタイプのデータベースに変換します。

または、オブジェクトの数が多すぎない場合は、コードファイルで文字どおりにロットを宣言するのが最も速い方法です。