1つの幅の広いテーブルまたは複数のテーマテーブル
私は、プレイヤーキャラクターが追跡したい多数の統計を持っている単純なテキストベースのゲームのデータベースを設計しようとしています。現在、私は関連する統計、スキル、財務、基本的な属性のいくつかのグループを持っています。次の設計のジレンマに私を導いている文字を含む1対1のかなりの数のフィールドがあります。これらの1対1のフィールドすべてを1つの非常に幅の広いテーブルに入れるか、テーマに基づいたテーブルに分割するか彼らのグループ？
すべてのフィールドを1つのテーブルに入れると、少なくとも20列のテーブルが表示されます。機能が増えると、さらに多くの列が表示される可能性があります。これにより、キャラクターの情報を入手する場所が1つだけになり、アプリケーションへのデータのロードが非常に簡単になります。ただし、1つのフィールドを更新しても残りのデータが壊れないようにする必要があるため、このような大きなテーブルのレコードを更新するのは面倒な作業になると思います。
データを分割すると、文字IDでリンクされた3つまたは4つのテーブルがあり、各テーブルには10列以下しかありません。これにより、データビューアの観点からデータが見やすくなり、更新の変動が少なくなると思いますが、すべてのプレーヤー情報を収集する必要がある場合は、さまざまなテーブルに対して複数のクエリを実行する必要があります。
データベース設計の経験が豊富な人がこれについてどう思うか知りたいです。データベースの正規化について少し読みましたが、1から1のデータではなく、リレーションシップによって結合されたデータを分割することに焦点を当てているようです。違いが生じる場合は、ASP.NET Entity Frameworkコードを最初に使用して、 SQL Server Expressのデータベース。
現在、いくつかのgroupsに関連する統計、スキル、財務、基本的な属性、およびその他のいくつかがあります。
まあ、それは実際に依存します。私はあなたの文章のキーワードを強調しました。
それらのグループが本当に「グループ」である場合、それらをテーブルに分割してみませんか？しかし、理由は「少なくともテーブルが大きくなったため」ではなく（少なくともパフォーマンスがまだ主な関心事ではない場合）、グループとして表示されるため、個別に作業できるためです。
テーブル間でデータを分割すると、アクセスが遅くなります（データを集計するにはいくつかのクエリが必要になるため）。ただし、このデータを独自に操作し、表示し、評価し、独自に開発することができます。
列が非常に多いため、マスターテーブルを分割する必要があるかどうかを質問しているようです。短い答えはノーです。以下でより長い回答に触れます。
データベースを見る単純な方法では、それはデータのグループとそれらのグループが表すものについてです。リレーショナルデータベースは、データのグループ間の関係、つまりリンクです。したがって、テーブルまたはテーブルのグループに何が入るかを考えるとき、このことを表すデータによって、いくつかの「エンティティ」の側面を考え出していることになります。ご存知のとおり、これはマスターテーブルと1つ以上の子テーブルで行われます。
例として、従業員。名前、Dob、ID番号、住所、電話番号、入社日などがあります。これらの一部は1対1、一部は1対nです。これが、設計の観点から見た場合の一般的な方法です。これにより、マスターテーブルといくつかの子テーブルが作成されます。
最新のデータベースのほとんどは、マスターテーブルが多数の列と考えるものを持っている場合は問題ありません。データベースにとって重要な場合は、10、20、100、なし。したがって、論理的な設計の観点からは、そのマスターテーブルを分割する理由はありません。しかし、現実世界と理論は常にうまくいっていない。これらの時間はまれであることを強調しなければなりません。多くの場合、データを別の方法で見ると、別の方法でデータを表現して問題を回避できます。本当に膨大な数の列があることに気付いた場合は、列が存在する理由を尋ね、別の視点から見てみてください。
従業員の例、電話番号に戻ります。ここにいくつかの数字があるかもしれません。では、自宅の電話用の列を携帯電話用に、さらに別の内線用に列を作成しますか？私はそうするかもしれませんし、私はそれのために子テーブルを作るかもしれません。そのテーブルには、id、category、numberの3つのフィールドがあります。したがって、マスターテーブルの3つの列のように見えたものが、実際には子テーブルに移動されます。同じデータですが、見方が異なります。
あなたの場合、これはおそらく家に近いと思いますが、私はここで推測していることを認めます。マスターテーブルの一部であるかのように見える文字を表す一連の統計を見ることができますが、実際には、それらは子テーブルとして簡単に表現できます。基本的な属性とスキルについて説明しましたが、どちらもマスターテーブルの一部である場合、どちらも赤信号になります。繰り返しますが、私はコンピューターとペンと紙の両方のゲームでのRPGの経験に基づいていくつかの仮定を行っています。ゲームが進化するにつれて、新しいスキルを追加する理由が見つかるかもしれません。新しい基本属性を追加することもできます。既存のスキルまたはベース属性を変更または破棄できます。データベースも変更しますか？理想的には、戻ってデータベース構造を変更したり、データベースレイヤーのコードを変更したり、システムロジックコードレイヤー、UIコードレイヤーを変更したりする必要はありません。このように変更して、コードにできるだけ影響を与えないようにします。だから、多分あなたはスキルテーブルを持っていて、各行はスキルです。同様に、各属性を行として持つ基本属性テーブル。これらのケースでは、従業員の電話番号と同様に、列ではなく行と言っていることに注意してください。
ぼくはぼろぼろになり始めたので、やめた。
だから、それはもっと長い答えです。要約すると、マスターテーブルには多くの列があるため、マスターテーブルを分割する必要はありませんが、それらの列を分析して、子テーブルの行のように別の方法で表現できないことを確認する必要があります。
お役に立てば幸いです。