質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
87.20%
MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

Laravel

LaravelとはTaylor Otwellによって開発された、オープンソースなPHPフレームワークです。Laravelはシンプルで表現的なシンタックスを持ち合わせており、ウェブアプリケーション開発の手助けをしてくれます。

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

解決済

冗長なキーを持ったテーブル設計をしてよいでしょうか。

love_engineerin
love_engineerin

総合スコア19

MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

Laravel

LaravelとはTaylor Otwellによって開発された、オープンソースなPHPフレームワークです。Laravelはシンプルで表現的なシンタックスを持ち合わせており、ウェブアプリケーション開発の手助けをしてくれます。

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

6回答

0評価

3クリップ

2401閲覧

投稿2021/12/06 03:38

編集2021/12/06 07:10

先生の作った授業を生徒が予約するようなサービスがあるとして、以下のようにテーブル設計しました。

teachers(id,name) lessons(id,name,teacher_id) students(id,name) lesson_reservations(id,lesson_id,student_id)

業務要件として、lesson_reservationsを取得する際には多くの場合でteachers.nameも取得したくなるとします。

その場合、上記のテーブル定義だとlesson_reservationsを取得する際にいちいちlessonsをjoinしてteachers.nameを取得しなくてはなりません。

テーブル定義としては冗長にはなりますが、lesson_reservationsteacher_idにすれば取得しやすいです。

もちろん、lessons.teacher_idが変更になるとlesson_reservations.teacher_idも変更が必要というデメリットはあります。

しかし、業務要件にこのような変更がないと考えた場合は、あえて冗長なテーブル設計をしてもよいのかなと思っています。

「このような場合は冗長な外部キーを持って良い」みたいに明記された設計パターンやその他情報があれば教えてほしいです。

良い質問の評価を上げる

以下のような質問は評価を上げましょう

  • 質問内容が明確
  • 自分も答えを知りたい
  • 質問者以外のユーザにも役立つ

評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

気になる質問をクリップする

クリップした質問は、後からいつでもマイページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

  • プログラミングに関係のない質問
  • やってほしいことだけを記載した丸投げの質問
  • 問題・課題が含まれていない質問
  • 意図的に内容が抹消された質問
  • 過去に投稿した質問と同じ内容の質問
  • 広告と受け取られるような投稿

評価を下げると、トップページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

m.ts10806

2021/12/06 03:40

プロジェクトや要件次第なので、他者がとやかく言える範囲ではないような
love_engineerin

2021/12/06 03:45

ありがとうございます! もちろんそうですよね! > 「このような場合は冗長なキーを持って良い」みたいに明記されたルールや情報 があれば自信を持てるなと思った次第です!
m.ts10806

2021/12/06 03:54

実プロジェクトの情報が外に出ることはないですし、想定のとおり動作していて不具合がないのなら文句はないのではと。 「好み」だけを語られても困りますよね?
love_engineerin

2021/12/06 04:01

>「好み」だけを語られても困りますよね? そうですね。好みではなくて、こういう設計パターンがあるみたいな情報がほしいです。 わかりづらくてすみません。文章を修正しました。 ありがとうございました。
hoshi-takanori

2021/12/06 06:24

「キー」と書かれると主キーや一意制約や外部キーのことを思い浮かべますが、もしかして単なるカラムのことでしょうか? 冗長なカラムを持つこと自体は場合によってはありかもしれませんが、キーに余計なものを含めると意味が変わってしまいます。
love_engineerin

2021/12/06 07:09

ありがとうございます! 仰るとおり曖昧な表現でした。今回は冗長な外部キーについての質問になります。 質問を修正します。
hoshi-takanori

2021/12/06 07:30

ごめんなさい、言葉が足りなかったですね。「キーに余計なものを含める」というのは、一つの複合キーに余計なカラムを追加するという意味で書きました。 lesson_reservations テーブルに teacher_id カラムを追加して、teacher_id 単独で teachers テーブルへの外部キーにするなら、それは単なるカラムの追加と大差ありません。 が、lesson_reservations テーブルの lesson_id と teacher_id を組み合わせた外部キーで lessons テーブルの id と teacher_id の組み合わせを参照する形になると、意味が変わってしまうので…。
love_engineerin

2021/12/06 07:42

ありがとうございます! その分類であれば、以下を想定しています。 >teacher_id 単独で teachers テーブルへの外部キーにするなら、それは単なるカラムの追加と大差ありません。
Kenji.Noguchi

2021/12/14 05:31 編集

マスターテーブル(ディメンジョンともいう)とトランザクションテーブル(ファクトとも言う)を分けて考えるのは一つの手で、マスターからトランザクションに属性の値をコピーするのは有りです。ご質問の例ですとteachersとstudentsとlessonsはマスターで、lesson_reservationsはトランザクションテーブルです。例えばレッスンの単価がlessonsにあったとしたら、lesson_reservationsに単価を毎回コピーしないと、単価が変更になった時過去の履歴まで影響が出てしまいます。また、先生と生徒程度の人数なら問題はないでしょうけれど、オンラインショップとか膨大な数を扱うdbで全マスターと毎回JOINしないといけないならパフォーマンスは望めないでしょう。稼働開始以来の全先生と全生徒と全レッスンをマスターに永遠に残さないといけない設計もやめた方がいいです。

まだ回答がついていません

会員登録して回答してみよう

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
87.20%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問

同じタグがついた質問を見る

MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

Laravel

LaravelとはTaylor Otwellによって開発された、オープンソースなPHPフレームワークです。Laravelはシンプルで表現的なシンタックスを持ち合わせており、ウェブアプリケーション開発の手助けをしてくれます。

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。