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