MongoDB との関係でそれを代弁することはできませんが、SQL データベースでは、いいえ、ベスト プラクティスではありません。それは、時折のユースケースがないかもしれないという意味ではありませんが、「ベストプラクティス」ではありません.
それらを日付として保存し、日付として取得します。最善の策は、データベースを UTC (大まかに「GMT」) として保存するように設定することです。これにより、データが移植可能になり、必要に応じて異なる現地時間を使用できるようになります (たとえば、データベースが地理的に多様なユーザーによって使用されている場合)。 、およびアプリケーション層で UTC から現地時間への変換を処理します (たとえば、Calendarまたはサードパーティの日付ライブラリを介して)。
日付を数値として保存するということは、データベースに対してレポートを作成したり、アドホック クエリを実行したりするのが難しいことを意味します。私は一度その間違いを犯しましたが、本当に正当な理由なしに繰り返すことはありません。:-)
それは以下に大きく依存します：
3 番目のポイントは、おそらく最も重要です。保存しようとしている値が実際に何を意味するのかを考えてください。野田時間を使用していないことは明らかですが、入力データに基づいて使用する野田時間タイプの選択に関するユーザー ガイド ページが、これについて明確に考えるのに役立つことを願っています。
Javaしか使用しておらず、データベースで日付/時刻型が十分にサポートされておらず、「特定の瞬間」ではなく「瞬間」のみを表現しようとしている場合。タイム ゾーン、オフセット付きのローカル日付/時刻、ローカル日付/時刻のみ、または日付のみ...) であり、診断ツールを作成してデータをより人間が読める形式に変換し、保存することに慣れています。 alongは合理的です。しかし、これは「if」のかなり長いリストです。
データベースで日付操作を実行できるようにする場合 (たとえば、月の最初の日に発生するすべての値を要求する場合) は、タイム ゾーンに注意して、おそらく日付/時刻型を使用する必要があります。(私の経験では、ほとんどのデータベースは、日付/時刻の型に関しては、少なくとも驚くほど文書化されていません。)
一般に、すべての要件を満たすことができ、その特定の環境を最も自然に表現できるタイプを使用する必要があります。そのため、操作時に問題が発生しない日付/時刻型を持つデータベース (たとえば、要求されていない方法で任意のタイム ゾーン変換を実行するなど) では、その型を使用します。それはあらゆる種類のものをより簡単にします。
より「プリミティブな」表現 (たとえば 64 ビット整数) を使用する利点は、データベースがそれをいじらないことです。そのアプローチのすべての通常の長所と短所 (主に短所) を使用して、データベースからデータの意味を効果的に隠しています。
それはさまざまな側面に依存します。標準の「エポックからの秒数」を使用し、誰かが整数精度のみを使用する場合、日付は 1970 年から 2038 年の範囲に制限されます。
しかし、精度の問題もあります。たとえば、UNIX 時間はうるう秒を無視します。毎日同じ秒数を持つように定義されています。そのため、UNIX 時間間の時間差を計算すると、エラーが発生します。
しかし、より重要なことは、すべての日付が完全にわかっていると仮定することです。これは、指定された日付の半分だけを表現する可能性がないためです。実際には、1 秒 (またはミリ秒) の精度ではわからないイベントがたくさんあります。したがって、表現が指定できる場合、たとえば日付の精度のみを指定できるのは機能です。理想的には、日付を精度情報とともに保存します。
さらに、カレンダー アプリケーションを構築しているとします。時間はありますが、現地時間もあります。多くの場合、両方の情報が必要になります。スケジュールが重複する場合は、もちろん、同期された時間でこれを最大限に実行できるため、ここでは long が適しています。ただし、現地時間の 9 ～ 20 時間外にイベントをスケジュールしないようにしたい場合は、タイムゾーン情報も常に保持する必要があります。複数の場所にまたがる場合は、日付表現にタイムゾーンを含める必要があります。表示されているすべての日付を現在の現地時間に変換できると仮定するのは、非常に単純です。
SQL の日付は奇妙な状況につながる可能性があることに注意してください。私のお気に入りの 1 つは、次のMySQL の不条理です。
SELECT * FROM Dates WHERE date IS NULL AND date IS NOT NULL;
はdate を持つレコードを返す場合0000-00-00 00:00:00がありますが、これは一般的なロジックの理解に反しています。
日付をできるだけ長く保存することはベストプラクティスではないと思います。これは、日付固有のクエリを実行できないことを意味するためです。お気に入り ：
where date between
また、SQL クエリを使用してテーブルから年月日を簡単に取得することもできません。
Java レイヤーで単一の日付形式コンバーターを使用して日付をそれに変換し、アプリケーション全体で単一の形式を使用することをお勧めします。
IMHO 、文字列を使用できる場合は、日付をDBに保存するのが最適です。したがって、Calendar のすべてのフィールドが必要ない場合は、不要なデータが server に行き来するのを避けてください。Calendar には大量のデータがあり、Calender の各インスタンスもかなり重いです。
したがって、必要なデータのみを含む String として保存し、必要なときにいつでも Calendar に変換して使用します。