データベースのテーブルを分割すべきか

Question

日報アプリを開発しています。
タスクAとタスクBがあり
現在はタスクAとタスクBを日報テーブル(reports)一つで管理しています。
a_info_(12)にはタスクAに関する情報(実際には具体的な名称が入ります)、b_info_(12)にはタスクBに関する情報(こちらも同様)があります。
user_idとdateの組み合わせがユニークキーです。
INSERTが一度だけ呼び出され、データベースに保存されます。
データを取り出す時は、当然ですがSELECTが一度だけ呼び出されます。

reports
 - id: integer
 - user_id: integer
 - date: date
 - a_info_1: varchar
 - a_info_2: varchar
 - b_info_1: varchar
 - b_info_2: varchar

これを分割して

reports
 - id: integer
 - user_id: integer
 - date: date
 - a_id: integer
 - b_id: integer

a
 - id: integer
 - user_id: integer
 - date: date
 - info1: varchar
 - info2: varchar

b 
 - id: integer
 - user_id: integer
 - date: date
 - info1: varchar
 - info2: varchar

のようにすべきでしょうか？
こちらも各テーブルuser_idとdateの組み合わせがユニークキーです。
このようにすると、INSERTを3回呼び出さないといけないのと、SELECTする際にはテーブルを結合する必要があり、煩わしいがするのですが、タスクAとタスクBの変更があった場合は改修が楽なのかなと思いました。
正規化に関してはできていないのかもしれません。

テーブルを分けるべきでしょうか？

Answer 1

利用方法によるんで正解はありません。あなたが判断して決めてください。

一般論で言えば「infoなんて項目名がそもそもどうなの？」とか「varchar何桁かわからんけど同じ桁数で良いならaとb分ける意味あるの？」とか色々ツッコミどころは満載ですが。

Comments

[k_k_kk]

えーと、正解はないにしてもベターな管理方法があると思ったので質問したのですが。

一般論というか、infoのカラムは仮の名称で実際には具体的な名前が入りますし、タスクA,Bに関しても具体的な名前が入ります。明言しなくてもわかると思いますが。

[gentaro]

書いてない事がわかるわけない。
あなたがズブの素人でそういう事をやってる可能性は多分にあるんだから、ちゃんと説明するのはあなたの義務。
そもそもどんなエンティティなのかわからん状態で設計上のアドバイスできるわけないのに、むしろ「そんなことも説明しないとわからないの？」という話なんだけど。

[phper.k]

gentaro さんの言葉はきついけど、言っていることは至極当然です。
（この質問読んだ時、同じように思った。）

[k_k_kk]

お二方ともコメントありがとうございます。
自分に至らなさがあり大変失礼いたしました。
今後は質問する上で前提となる情報を、より具体的に伝えることを心がけていきたいと思います。

Answer 2

エンティティが同じなら分けるべきではありません。

現在はタスクAとタスクBを日報テーブル(reports)一つで管理しています。

その識別が欲しいなら、識別可能な項目を追加すれば良いかと。

reports
 - id: integer
 - user_id: integer
 - date: date
 - task_id: varchar
 - info_1: varchar
 - info_2: varchar

※a_infoとb_infoはどちらか一方ではなくそれぞれで必要なら、task_idもプライマリーにしたテーブルに分割ですね。

reports
 - id: integer
 - user_id: integer
 - date: date

reports_detail
 - reports_id: integer
 - task_id: varchar
 - info_1: varchar
 - info_2: varchar

Comments

[k_k_kk]

具体的でわかりやすいご助言をいただきありがとうございます！とても勉強になりました。