Q&A
要件次第ですよ。あるといえばあるし、ないといえばない。なので、要件提示されないと判断できません。
データーベースに入れる日付ですが、ミリ秒まで入れるケースはありますか？
ユーザーの履歴を保存しようと思っているのですが、一般的にはどのような形式で入れますでしょうか？
date("Y-m-d H:i:s")
でいいと思いますか？
ミリ秒まであった方が便利だったりするのでしょうか？
ミリ秒あってよかったこと、なくて困ったことなど事例があったら教えてほしいです。
宜しくお願い致します。
回答4件
0
手っ取り早い回答
一般的にミリ秒は必要有りません。
以下感想です
ユーザー履歴にミリ秒は必要か？というシステム要件の話なので
お仕事なのであれば要件を決めている人に確認しないとマズい事になりかねません。
ご自身が要件を決める側であるならクライアントからのヒアリングで要不要を決めていくしかありません。
どちらでも無い、例えば自作の趣味サイトでの話であるならば、
私の場合なら今使いみちが思いつかないのであれば入れないです。
その上でミリ秒を使うケースはあるか？といえばこれくらいです。
- ミリ秒単位でどんどん履歴が貯まりこのカラムで発生順を担保するのでそもそも必須
- 画面に表示する時ミリ秒を出してデザイン的にカッコよさげにする
ミリ秒が必要な場合は設計時にミリ秒が必要だと大体分かるので
繰り返しになりますが今思いつかないのであれば入れなくても良いと思います。
投稿2020/03/29 05:00
総合スコア31
> 繰り返しになりますが今思いつかないのであれば入れなくても良いと思います。
逆じゃないですか？
当然、現時点でちゃんと判断するのが最善であるという前提はありますが、もしいま判断できないなら、後から精度を落とすことは可能なので入れて良い気がしますが。
むしろ運用開始後にミリ秒まで必要であるケースが発生する方がマズい気がします。
※引用箇所が「自作の趣味サイトでの話」に掛かる事は共有されているとします。
判断出来ないけど不安だから全部マシマシで行こうという対応はエンハンス・運用に於いて多大なコストになりがちです。
"結局使わない仕様・機能のせい"で"改修コストが上がる"のも"マズい"のではないですか？
ミリ秒まで入れることと
> エンハンス・運用に於いて多大なコストになりがち
が繋がりません。
どういうケースを想定しているんでしょう？
精度を上げる必要が出てきた時にむしろコストが上がる気がしますが。（低精度・高精度が混在する問題をどうするのか考えないといけない）
> 判断出来ないけど不安だから全部マシマシで行こうという対応はエンハンス・運用に於いて多大なコストになりがち
というのは一般論をお伝えしています。
一般論ではなくmousuguharudesuさんの状況ではどうか、というお話はそもそもあまりに情報が
無い為、「ミリ秒」の点だけを注視して議論しても全くの無駄です。
質問者が書いてる情報からしか状況が読み取れないからこそ、書かれている事にストレートに回答すればいいだけだと思いますけど。
そうじゃないなら「質問への追記・修正、ベストアンサー選択の依頼」で質問・確認すべきですよね。
その前提で「ミリ秒」を入れることで発生するデメリットを具体的に示せないのに「入れなくて良い」とするなら、それは適切な回答とは思えませんが。
私は私なりの回答をお出しし何故そう考えるかも記載しております。
"入れなくて良い"という回答の根拠も同様です。
あなたのべき論に興味はありませんし、そう思うのであればあなたはそうすれば良いのではないでしょうか。
まぁ私もあなたの考えにさほど興味はありませんが、質問者のベストアンサーを見れば客観的にどういう回答が求められているのかはわかると思いますけどね。
今回の仕様は複数ユーザーがおり、masunatt0さんの「>ミリ秒単位でどんどん履歴が貯まり」に当てはまります。この点はgentaroさんも同様に仰っているので、お二方のご意見の通りミリ秒を入れるように致します。大変勉強になる議論をありがとうございます。
分かりやすいタイミングでどうもありがとうございます。
"質問者のベストアンサー"で客観性を計る人の見識は大変参考になりました。
こちらこそ。明確な根拠も示せず視野の狭い回答しかできない方の見識はよくわかりました。
結局「一般的にミリ秒は必要有りません。 」という私の回答1行目のみに着目、憤慨しロクに中身も読まずに突っかかってきただけでしたね。
これからはちゃんと文章を読み解くようお願い致します。
ここはあなたの日記帳ではないので、書かれた内容に責任持ちましょうね。
私は自分の回答を記載しその根拠も述べていますが？
それを全く無視して「お前の回答は間違っている」と言われても困ります。
ミリ秒まで入れて困ることってありますかね。切り捨てる必要性を感じません。
書かれている事がまるで筋が通ってないから指摘しているんですけどね。
自分が正しいと思うなら「ミリ秒」を入れないメリットや入れるデメリットをもうちょっとちゃんと説明してくださいよ。簡単な事じゃないですか。具体例を挙げればいいだけですよ。
それもわからず、単なる指摘を攻撃を勘違いされているなら、単なる被害妄想の人だと思う他ありませんが。
「どういうケースを想定していますか？」と質問したとおり、こちらは最大限あなたの話を理解しようと思ってますし、そこで納得のいく説明があれば新たな知見が得られるので高評価しようと思って尋ねたんですがね。
まぁ話が通じない人ならいいや。
そもそもそういう論点では無いし、質問者ではなくあなた独自の質問に回答する謂れも無いんですよ。
ましてや礼節も知らない人に対して。
もしかして世の数多あるシステムの殆どがDBにミリ秒単位で格納しているとでも思っているのですかね。
してるんじゃないですか？
どうにも会話が不自由な人っぽいけど、時系列的に見れば礼節を欠いた対応をしだしたのはあなたですけどね。
こっちは思考の経緯をちゃんと伝えて質問しているのに対して
> あなたのべき論に興味はありませんし、そう思うのであればあなたはそうすれば良いのではないでしょうか。
こういう回答してるじゃない。これで自分が礼節正しいとでも？
どういう教育を受ければそうなるのか教えてほしいです。
あとミリ秒単位で保持しているDBが多い少ないってそんなに問題なんですか？
質問は
> ミリ秒あってよかったこと、なくて困ったことなど事例があったら教えてほしいです。
なんだから、それに回答すりゃいいのに「必要ない。根拠は俺がいらないと思っているから」で通用すると思ってるんですか？すげー理論。
0
日に一度しか発生しない履歴であれば日まで、秒単位で発生する履歴であれば秒単位で、一秒間で何度も発生するのであればミリ秒なりマイクロ秒ナノ秒単位で。要件によるのではないでしょうか。
要件がよくわからず決められないのであれば、datetime型やtimestamp型の精度を確認したうえで、わたしならまずはその型を使っておくかな。
投稿2020/03/29 04:02
総合スコア3990
0
DB が用意している時間関係のデータ・タイプから、あなたの要件に適切とおもわれるものを使えばよいです。
日付型と時刻型(DATE, TIME, DATETIME, TIMESTAMP, YEAR)
https://www.dbonline.jp/mysql/type/index4.html
ユーザー履歴なら、Timestamp で 小数部の桁数も最大まで指定しておくのがよいです。
１秒の間に何十件もユーザー履歴が登録されるようなサイトだったら、秒単位までしか記録をとっておかなかったとすると, 履歴を時間順に並べることが困難になる可能性があります。
(プライマリーキー の大小で判定ができるかもしれませんが)
投稿2020/03/29 06:34
総合スコア22324
リンクありがとうございます。ミリ秒を入れようとしたらエラーとなったため、ちょうど探していた情報でした。
リンクありがとうございます。ミリ秒を入れようとしたらエラーとなったため、ちょうど探していた情報でした。
0
ベストアンサー
要件次第であるというのは他の方も仰っているとおりですが
ミリ秒あってよかったこと、なくて困ったことなど事例があったら教えてほしいです。
複数人が同時に更新（INSERT）する可能性のあるテーブルで、システムの不具合によりデータ不整合（仕様上はありえないデータの状態）となった時に、正確に更新順（各ユーザーの操作順）を把握するためにミリ秒まであって良かった、というケースはあります。
投稿2020/03/29 05:22
総合スコア8949
あなたの回答
tips
プレビュー
