質問: ### 前提 DB設計の初心者です。業務でDBを触ったことがなく完全に独学です。今回個人的に、スポーツ競技の戦歴・戦果(以降まとめて戦歴とします)をチーム・個人でそれぞれ管理するアプリケーションを作りたく、それらの戦歴を管理するためのDB設計を考えているですがなんとなくのイメージに起こすところまではできたのですがそのイメージが最適なのかわからず、皆さんならどうされるかアドバイスがいただきたく質問させていただきました。データ構造的にRDB(SQL Server)を使うべきなのかも疑問を感じているので、それ以外に最適な方法がありましたら併せてご教示くだされば幸いです。また、技術が熟練してきた暁には仕事としてDBを使ったアプリケーションを作ったりしたいと考えているので、小規模ならとりあえず動かすということよりもシステム設計としてどうなのかという視点からご意見くださいますと大変参考になります。 ### 実現したいこと 作りたいアプリケーションには個人アカウントとチームアカウントがあり、それぞれで戦歴を管理したいと考えています。 まず、個人における戦歴の場合、個人戦における戦歴とチームメンバーとしての個人という2つの戦歴パターンが考えられるかと思います。 ###### 個人戦における戦歴データ これには * 競技(ゴルフなのか卓球なのか...) * "勝ったか負けたか引き分けたか"あるいは得点などの競技を競技たらしめるデータ 最低限このデータが含まれ、競技に応じてファウルの回数や対戦相手(1人の場合もあれば複数人の場合もある)などの 情報が含まれることになるかと思います。 ###### チームメンバーとしての個人の戦歴データ これはチームメンバーとしてなので1つ上のレイヤに"**チームとしての戦歴データ**"が存在し、そこに個人戦における戦歴での最低限のデータにあたる部分のデータが含まれ、個人の戦歴としては競技に応じた情報が記録されることになるかと思います。 ### 考えた設計 まず自分なりに以下のようなに大雑把なテーブル設計を考えました(中身はサンプルです) ###### 個人とチーム 個人とチームはそれぞれユニークなIDを持ちます ###### 試合形式 | 形式ID | 形式 | | --- | --- | | 1 | 団体 | | 2 | 個人 | | 3 | 団体・個人 | ###### 競技マスタ | 競技ID | 競技名 | 試合形式 | | --- | --- | --- | | 1 | 野球 | 1 | | 2 | ゴルフ | 2 | | 3 | 卓球 | 3 | ###### 試合テーブル | 試合ID | 競技ID | 試合形式 | 対戦日(時) | 個人戦歴ID | チーム戦歴ID | ユーザーID | チームID | | --- | --- | --- | --- | --- | --- | --- | --- | | 1 | 1 | 1 | 2019-01-01 | 1 | 1 | 1 | 2 | | 1 | 1 | 1 | 2019-01-01 | 2 | 1 | 2 | 2 | | 3 | 2 | 2 | 2019-01-01 | 1 | null | 3 | null | | 4 | 3 | 2 | 2019-01-01 | 1 | null | 4 | null | ###### 野球_チーム戦歴テーブル | 試合ID | 対戦チーム1 | 対戦チーム2 | チーム1得点 | チーム2得点... | | --- | --- | --- | --- | --- | | 1 | チームID | チームID | 2 | 3 | ###### 野球_個人戦歴テーブル | 試合ID | ユーザーID | ポジション | 打数 | 打席数... | | --- | --- | --- | --- | --- | | 1 | ユーザーID | サード | 2 | 3 | 一部しか記載できておらずこれで伝わるか不安ですが、"試合"は競技問わず同じテーブルに記録し、その下に競技ごとに個人・団体のテーブルを作り記録するイメージです。 ### 引っかかること(聞きたいこと) ###### 競技ごとにテーブルを作るのは最適な手段なのか? 競技によって記録する情報が異なるため異なる競技の詳細な戦歴データを共通のテーブルに格納することはレコードに何らかのデータをフォーマットした文字列(jsonなど)を埋め込まない限りできないかと思います。 こうしてしまった場合、ソートができない、検索ができないなどの問題があるのでこれは好ましくないかと思います。 そうなったとき競技ごとにテーブルを作るしかないように思えるのですが、例えばマイナースポーツまですべてカバーしようとした場合(個人でやるのが現実的かどうかは別として)テーブルの数が膨大になってしまうかと思います。 これは問題のないことなのでしょうか? ###### 本当にRDBを使うべきなのか? このような場合本当にRDBを使うべきなのか、それが最適なのかRDBの知識しかない私にはどうも引っかかってしまいます。何か別のソリューションが存在するような気がしているのですが、如何せん知識不足なものでよくわかりません。 ### 最後に 質問になっているかどうかすらも怪しく、言葉の整合性も取れていないかと思いますが疑問を自分なりに頑張って言語化したつもりです。どうか皆様のご回答のほどよろしくお願いします。
回答: データを正規化するのがRDBの原則ですが、正規化データでは球技場などしか共通のテーブルを使える物は無いでしょう。 統括して何がしたいのかに因りますが、戦歴データなど蓄積だけしか行わないならNoSQLなどの出番かも知れませんね。 最近のRDBはXMLやJSONでもインデックスは使えますし、とりあえず手頃なものからやってみて問題点を洗い出すのが良いと思いますよ。