1

マルチプレイヤーをサポートしているかどうか、ジャンル、リリース日など、ゲームに関連するプロパティを格納するデータベースの設定に取り組んでいます。

カテゴリタイプごとに2つの追加テーブル（genres、genres_dataなど）を作成することは、それほど動的ではないようです。私の最初の考えは、2つの方法のいずれかを設定することでした...

骨格情報を含むゲームテーブル、すべてのプロパティを一覧表示するプロパティテーブル、およびゲームに関連するすべてのデータを含む3番目のテーブルを用意します。ここでは、基本的に各プロパティに関連する列のみが使用されます。

games
-----------
game_id
... relevant data

properties
-----------
property_id
title
type
category

properties_data
---------------
game_id
property_id
bool
min
max
date
text(max255)
longtext

または、ゲームテーブルを同じにし、プロパティに列名を含めてから、3番目のテーブルの列を使用します。

properties
--------------
property_id
title
type
category
column_name

properties_data
----------------
game_id
title
description
release_date_au
release_date_jp
genre_rpg
genre_fps
platform_360
platform_ps3
platform_pc
has_leaderboards
has_downloadable_content
... etc

この種のシナリオでは、行に関連する5ダースほどのタイプのデータがありますが、各カテゴリに多数のカテゴリとサポートプロパティがある場合の実際的なアプローチは何ですか？（私には）各プロパティタイプまたはカテゴリのテーブルを作成するのは効率的ではないようです。

4

2 に答える 2

3

これは、テーブルの典型的なスーパータイプ-サブタイプクラスターのようです。あなたがそれをそのように特定していないことを除いて。したがって、正式に識別し、データを正規化します。

  • スーパータイプ（親）に共通の列を配置します
  • 各サブタイプに固有のすべての列を個別の子テーブルに配置します
  • オプションの列がなくなるようにします
  • その場合は、別のレベルのサブテーブルが必要です。

「動的に」入力されたテーブルを選択すると、（コードではなく）DDLで定義されたbusienssルールを使用してデータベース内の静的テーブルのすべての制御が失われます。その場合、これらの大まかに定義されたテーブルは、データの整合性がない混乱として終わることで有名であることに注意してください。この最近の回答を読んで、状況を把握してください。

関連する回答へのリンク

重要なのは、その「動的」なことを行う場合は、それを適切に行うことです。

しかし、私はあなたがそこまで行く必要があるとは思わない。通常のRdbを使用すると、完全なリレーショナルパワーと柔軟性を維持できます。より多くのテーブルはRdbの性質であり、恐れることはありません。適切に行われると、完全な制御と速度が得られます。これで最初のパラに戻ります。

于 2010-11-29T23:27:49.740 に答える
1

属性の説明から-3番目のオプションが適切であるようです。

games
--------
game_id
name
...

release
----------
release_id
game_id
release_date
release_country

genre
---------
genre_id
name

game_genre
-----------
game_id
genre_id
于 2010-11-29T19:40:22.740 に答える