Q&A
ある日のグラフを表示したときに、その日の指定が入った「週のグラフに対するコメント」は表示するんですか？
あるいはある週のグラフを表示したときに、その週に含まれる日付のコメントは表示するんですか？
ユーザが指定した日付の１日/１週間のデータをグラフ表示し、それぞれに対してコメントを入力保存できるWEBアプリを考えています。
因みに1週間のグラフはユーザが指定した日から一週間ではなく、指定した日の該当する週のデータをグラフで表示しようと考えています。
そこで下記モデルを検討しているのですが、あまりよくないでしょうか？(データモデルが別にあり)
ユーザが指定した日を該当する週に変換してからデータを扱うので、少し変かなとは思っています。
ご意見いただければ幸いです。
コメントモデル
ユーザID
日付
日/週 (1日のグラフか1週間のグラフか判断するデータ)
Aデータコメント
Bデータコメント
Cデータコメント
ある日のグラフを表示したときは、「日のグラフに対するコメント」だけを表示します。
ある週のグラフを表示したときは、「週のグラフに対するコメント」を表示します。
回答3件
0
ユーザが指定した日を該当する週に変換してからデータを扱うので、少し変かなとは思っています。
これ自体は別に変な事ではありませんが、
- 日に対するコメント
- 週に対するコメント
がそれぞれ別の性質を持つデータなのであれば、テーブル自体を分けてしまってもいいと思います。
逆に、
コメント対象の範囲が違うだけで他の性質は全く同じであるべきである
という事であれば、フラグによる管理を行う現在のテーブル構造はよくある形かと思います。
あとは、
今後、年に対するコメントとか、10年に対するコメントとか範囲が拡張される可能性があるのであれば、
コメント対象範囲テーブル
を用意して、
コメントテーブルの日/週 (1日のグラフか1週間のグラフか判断するデータ)をコメント対象範囲ID(FK)
にしておくことで拡張に対応しやすくなります。
（範囲が拡張される可能性が0ならこれも必要ありません）
[質問追記前の回答]
日付が記録されているのであれば、
(そこから日も週も選択/取得出来るので、)
よほど大きな理由が無い限りは日も週もDBには保存しないのが一般的です。
投稿2019/06/12 00:14
編集2019/06/12 02:27
総合スコア18711
ご回答いただきありがとうございます。
6月1日が週の始まりの日だとした場合、6月1日には週と日の両方のコメントが必要になるのですが、日付から日も週も選択/取得できるのでしょうか。
申し訳ありませんが、仕組みをご教示願います。
ああ、週そのものに対するコメントという事ですね。
追記を読んで理解しました。
であれば、「日/週 (1日のグラフか1週間のグラフか判断するデータ)」は必要だと思います。
（データの性質が違うので、テーブルそのものを分けてしまった方が後々の管理は楽になるかもしれませんが、どちらもあり得る実装だと思います。）
日付とは別の観点としては
- Aデータコメント
- Bデータコメント
- Cデータコメント
をフィールドとして持ってしまうと、データ種類の増量（データDが発生した場合）に対応できなくなるので
- 対象データID（FK）
- コメント本文
として、対象データを別テーブルで管理する方が良いですね。
（データの種類がA～Cで永久に固定ならこれも分ける必要は無いです）
ご意見いただきありがとうございます。
日/週だけではいけないと私も思っていて、グラフの表示期間にしようかと考えていました。
又、データが固定である保証はないので拡張性についても検討してみます。
要件の固定が保証されていないようであれば、
第三正規形まで正規化しておけば多くのケースに対応出来るので、
方向性として検討されると良いかもしれませんね。
貴重なご意見いただきありがとうございます。
検討してみます。
0
ベストアンサー
ユーザーが指定した条件と結果へのコメントを格納するテーブルだとすると、指定した条件が同じだった場合に何が違うかが分からないですね。
その出力を行った時系列を表す情報があった方が良いかと思います。
もう１点としては、そのグラフデータはコメントを付けた時点のものを再現できるのかという事ですね。
グラフの元データに変更が無い前提なら、条件を元に再現すればコメントと一致しますが、データが変わるなら、コメントと一致しない事になるので。
投稿2019/06/12 01:21
総合スコア25173
ご回答いただきありがとうございます。
日/週を判断する要素があれば、指定条件が同じにはならないと一応考えてはいます。間違っているかもしれませんが。
確かに出力したときのグラフに関する時系列情報等を保存しておいたほうが
今後いろいろ対応できそうな良い設計な気が私も感じます。検討してみます。
一応今回の仕様としては、当日のデータ等は時間とともに変化してしまいますが、それは割り切り事項にしようとおもってはいます。
想定している運用で同じ条件にならないという事はあるかもしれませんが、システム的に同じ場合は入力を許さない仕様でない限り、同じ条件の場合は考慮すべきです。
その際に追加するのか更新するのかも検討が必要です。
こういった類の出力については、随時出力可能で、出力するものが変化するならPDFなりで出力して、コメントと共にセットで保存するというのが考えられる事です。
ご意見いただきありがとうございます。
たしかに随時変化するので、日に何度も残せるほうがよい仕様な気がします。
検討してみます。
出力されたものを確定するなら、そのデータの管理用のテーブル等が必要になり、それに合わせてこのコメントについてはリレーションの為の項目が必要になりますね。
内容からすると、複数人がコメントする前提だと思いますので、同じデータについて行う必要があるので、データが変化してしまうのはよろしくないですね。
データを確定させてから、各々コメントする事になるはずですから、データの管理情報の方に条件を持たせる必要がありますので、条件と、コメントはテーブルを分けた方が良いことになります。
貴重なご意見いただきありがとうございます。
自分の検討不足を思い知らされます。
0
日付が保存されているなら、日/週は計算で出せるよ。
投稿2019/06/12 00:58
総合スコア3307
ご回答いただきありがとうございます。
6月1日が週の始まりの日だとした場合、6月1日には週と日の両方のコメントが必要になるので、日/週のどちらかを判断するために用意したのですが、考えがまちがっていますでしょうか。
週も曜日も日付から計算で出せます。
日付から計算して週の初めなら、こっち。とか分岐作れば済む話です。
それだけソースコードの量は長くなりますが、それも仕方のない事です。
判断基準が分かりませんが、無駄なデータになるので保存は基本的にはしないでしょう。
週の初めの日は、日のデータに対するコメントと週のデータに対するコメントの二つが必要と考えています。
ご意見いただきありがとうございます。
@stdioさん
内容を勘違いされて、噛み合ってないと思います。
> 日/週 (1日のグラフか1週間のグラフか判断するデータ)
あなたの回答
tips
プレビュー
