テーブル設計 どちらが正しいのでしょうか？

Question

テーブル設計に関する質問です。

今、営業の日報のようなものをDB登録しようと考えています。
営業は一日に複数の顧客のところへ行き、それぞれに対して1レコード程度の報告を行う。
テーブル設計としてどちらが正しいですか？

A. 1テーブル

daily_reports
|id|ユーザID|日付|枝番|data1|data2|data3|....|
|----|----|----|----|----|----|----|
|1|1|20210617|1||||
|2|1|20210617|2||||
|3|1|20210617|3||||
|4|2|20210617|1||||
|5|2|20210617|2||||

B. 2テーブル

daily_reports

id	ユーザID	日付
1	1	20210617
2	2	20210617

daily_report_dt

id	レポートID	枝番	data1	data2	data3	....
1	1	1
2	1	2
3	1	3
4	2	1
5	2	2

正規化の観点からみればBが正しいのでしょうが、
親テーブルの持つ情報が少なすぎて何か気持ち悪いというか違和感が出てしまいます。
ただ、Aの場合もテーブル名が日報にも関わらず、同ユーザ同日のものが複数できるのもおかしいですよね。。。
親テーブルの情報量の少なさは判断に影響しないのですかね？

DB設計の初心者なので稚拙な質問かもしれませんがよろしくおねがいします。

Comments

[m.ts10806]

「どうなったら正しいと判断できるか」自身の中に基準をある程度持っておかないとアドバイスを鵜呑みにしてしまって運用に合わない形になる可能性もあります。
何をキーとするかは作る人が決めなければなりません

[hihijiji]

> 気持ち悪いというか違和感が出てしまいます
そうゆう場合は使わなくても、表題, 提出時間, 承認者IDとかそれっぽいのを
入れておくといいです。

Answer 1

変更耐性やデータ一貫性の観点からはBのケースがよいと思いますが、それが100%最適ではありません。
状況に応じてどこまで正規化するかを検討する必要があります。

• データをどのような単位で取得・検索するのか（頻繁にSELECTするユースケースで利便性が高いのはどちらか）
• データの総量はどのくらいあるか（結合することでパフォーマンスに影響しないか）
• 今後親テーブル側に情報が追加される可能性はどのくらいあるか（たとえば日報テキストなど将来追加はないか）

などの情報をもとに、どちらがより良いかを判断することになります。

「正規化を崩すか」のさじ加減は運用してみないとわかりづらいですが、
判断するための軸をざっくり言うと、

1. パフォーマンス面で直近の問題にならないか？
2. 将来変更するのが容易なのはどちらか？

のような観点と優先度で判断するとよいですね。
1については数百万〜数千万といった規模のレコードにならなければたいてい大丈夫なので、
情報がないなかで判断するとしたら、個人的にはBを選択するのがよいかなと思いました。

ただ、Aの場合もテーブル名が日報にも関わらず、同ユーザ同日のものが複数できるのもおかしいですよね。。。

単にテーブル名の問題でしたら、reportsのようなテーブル名にしてもよいかもしれませんね。

親テーブルの情報量の少なさは判断に影響しないのですかね？

現時点での情報量の少なさでは判断しなくてよいかと思います。
2〜3カラム位の小さなテーブルはよくあります。

Comments

[p19ljk]

回答ありがとうございます。

>変更耐性やデータ一貫性の観点からはBのケースがよいと思いますが、それが100%最適ではありません。
>状況に応じてどこまで正規化するかを検討する必要があります。
やはり、意味合い的な関係だけでは本来の正解は導き出せないですよね。
指摘いただいた考慮点を含め再度検討してみます。

ありがとうございます。

Answer 2

考え方としては正規化しているBが正しいですが
命名方法が微妙ですね

daily_report_dtの「レポートID」は「ユーザーID」であるところです
本来のレポートIDはdaily_report_dt自体のIDのことです

Comments

[p19ljk]

コメントありがとうございます。

> daily_report_dtの「レポートID」は「ユーザーID」であるところです
> 本来のレポートIDはdaily_report_dt自体のIDのことです
レポートIDをユーザIDにしてしまうと、daily_reportsの明細であるdaily_report_dtがユーザに紐付いてしまうのではないでしょうか？

[yambejp]

そうですね、ちゃんとやるならユーザーテーブルを作ってユーザーIDで連携して下さい

[p19ljk]

上記に書かれていませんが、もちろんユーザテーブルは存在し、daily_reportsのユーザIDはユーザテーブル上のidと連携されています。
しかしdaily_report_dtはdaily_reportsと親子関係なため、レポートIDをユーザIDにすべきではないと考えます。