web-dev-qa-db-ja.com

追加の列を持つ単一のテーブルとスキーマを複製する複数のテーブル

ある時点で、データベースで、すべてのレコードが使用するわけではない複数の列を含む単一のテーブルを使用するか、またはスキーマが重複する複数のテーブルを使用するかを決定する必要があるプロジェクトに取り組んでいます。

複数のスポーツに対応できるスポーツ情報アプリを作成しています。たとえば、NBA、NHL、MLB、NFLを処理できます。各スポーツには非常によく似たコンセプトがあります-チーム、スケジュール、怪我、選手情報..

もちろん、データソースは、同じスキーマ内の各データを提供するわけではありません。各スポーツには、ベンダーからデータを受け取る異なるスキーマがあります。

データフィードの事前分析を行って共通点を特定するのに十分な時間（クライアントの要求）がなかったため、私は自分の賭けをヘッジして「安全な賭け」を取り、すべての1セットのテーブルではなく、スポーツごとに個別のテーブルを作成しました。中古スポーツ。

その結果、いくつかのテーブルでスキーマが複製され、データベース（ストアドプロシージャなど）へのインターフェースも複製されます。 NBA_Game、NFL_Game、NBA_Team、NFL_Teamなどのようなものがあります。各テーブルには、他のテーブルにはないいくつかのプロパティがあり、いくつかは共有されています。それは、例えば4つか5つのスポーツで5-10のテーブルに続きます。これが完全に悪いことかどうかはまだわかりません-別の方法では、すべてのスポーツで使用されるわけではないプロパティを持つテーブルの単一のセットがあるため、それだけでは扱いにくい場合もあります。

これを行った人がこの種のデザインの落とし穴に遭遇し、ここでその経験を共有できますか？道を進んで学習する代わりに、今私が知るのに役立つかもしれないことは？すべてのレコードが使用するわけではない列を使用して、1つの大きなテーブルまたはテーブルセットを使用して、他の方法でそれを実行しましたか？その際に陥った落とし穴は何ですか？

過去に使用した table inheritance など、より効果的な代替策はありますか？

ありがとう

databasedatabase-designrelational-database
13
dferraro

あなたが話しているのは データベースの正規化 です。完全なデータモデルなどは存在せず、正規化が多いほど良いとは限らないことを知って安心するかもしれません。正規化は、データモデルとデータベースのパフォーマンスを明確にするという点でコストを課す可能性があります。したがって、選択するbestモデルは、使用要件によって異なります。

表面的には、あなたの例は概念的にはよく似ており（X_Game対Y_GameおよびX_Team対Y_Team）、いくつかの列の余分なオーバーヘッドは不合理に見えません。とはいえ、各スポーツでテーブルに数十列の列が追加される場合、実際には扱いにくくなります。

その場合、共通のデータは中央のテーブルに保持され、スポーツ固有のデータはリンクされたデータ構造に保持されるハイブリッドモデルを検討することをお勧めします。何かのようなもの：

table Game {
    gameId int,
    teamId1 int fk,
    teamId2 int fk
}

table HockeyGame {
    gameId int fk,
    penaltyMinutes int
}

table BasketballGame {
    gameId int fk,
    freeThrows int
}
5
Midnotion