回答編集履歴
2
追記
answer
CHANGED
|
@@ -16,6 +16,7 @@
|
|
|
16
16
|
を用意して、
|
|
17
17
|
コメントテーブルの`日/週 (1日のグラフか1週間のグラフか判断するデータ)`を`コメント対象範囲ID(FK)`
|
|
18
18
|
にしておくことで拡張に対応しやすくなります。
|
|
19
|
+
（範囲が拡張される可能性が0ならこれも必要ありません）
|
|
19
20
|
|
|
20
21
|
---
|
|
21
22
|
[質問追記前の回答]
|
1
補足
answer
CHANGED
|
@@ -1,3 +1,24 @@
|
|
|
1
|
+
> ユーザが指定した日を該当する週に変換してからデータを扱うので、少し変かなとは思っています。
|
|
2
|
+
|
|
3
|
+
これ自体は別に変な事ではありませんが、
|
|
4
|
+
|
|
5
|
+
- 日に対するコメント
|
|
6
|
+
- 週に対するコメント
|
|
7
|
+
|
|
8
|
+
がそれぞれ別の性質を持つデータなのであれば、テーブル自体を分けてしまってもいいと思います。
|
|
9
|
+
逆に、
|
|
10
|
+
コメント対象の範囲が違うだけで他の性質は全く同じであるべきである
|
|
11
|
+
という事であれば、フラグによる管理を行う現在のテーブル構造はよくある形かと思います。
|
|
12
|
+
|
|
13
|
+
あとは、
|
|
14
|
+
今後、年に対するコメントとか、10年に対するコメントとか範囲が拡張される可能性があるのであれば、
|
|
15
|
+
`コメント対象範囲テーブル`
|
|
16
|
+
を用意して、
|
|
17
|
+
コメントテーブルの`日/週 (1日のグラフか1週間のグラフか判断するデータ)`を`コメント対象範囲ID(FK)`
|
|
18
|
+
にしておくことで拡張に対応しやすくなります。
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
[質問追記前の回答]
|
|
1
22
|
日付が記録されているのであれば、
|
|
2
23
|
(そこから日も週も選択/取得出来るので、)
|
|
3
24
|
よほど大きな理由が無い限りは日も週もDBには保存しないのが一般的です。
|