私はデータベースで作業していますが、1 つの日付列ではなく、複数の列 (日、月、年) でテーブルが設定されていることがわかります。私はそれを1つに変換する必要があると考えていますが、それには多くの意味があるかどうかを確認したかった.
サイトを書き直しているので、とにかくそれを処理するコードを更新していますが、そのようにすることで何か利点があるかどうか興味がありますか?
それが使用される唯一のことは、すべての列が比較されるデータの比較であり、整数の比較は日付の比較よりも高速であると思います。
私はデータベースで作業していますが、1 つの日付列ではなく、複数の列 (日、月、年) でテーブルが設定されていることがわかります。私はそれを1つに変換する必要があると考えていますが、それには多くの意味があるかどうかを確認したかった.
サイトを書き直しているので、とにかくそれを処理するコードを更新していますが、そのようにすることで何か利点があるかどうか興味がありますか?
それが使用される唯一のことは、すべての列が比較されるデータの比較であり、整数の比較は日付の比較よりも高速であると思います。
それらを単一の列に統合します。単一の日付のインデックスは、3 つの int の複合インデックスよりもコンパクトになります (したがって、より効率的です)。また、DBMS が提供するタイプ セーフと日付関連の機能も利用できます。
年の月または日でクエリを実行したい場合でも (説明から判断すると、そうではないようです)、それらを個別に保持する必要はありません。適切な計算列を作成し、それらを intex するだけです。
通常、単一の日付フィールドが理想的です。より効率的な比較、低レベルでの有効性チェック、およびデータベース側の日付計算関数が可能になるためです。
コンポーネントを分離することの唯一の重要な利点は、日または月の最初の検索 (比較) が頻繁に必要になる場合です。「この日に起こった他の出来事」のようなものかもしれません。または、毎月の予算編成アプリケーションか何か。
(それでも、適切なインデックスを作成することで、適切な日付フィールドを効率的に機能させることができます。)
日付列は、目的に適しているため、時系列データに適しています。
ただし、完全な日付を使用するのではなく、月ごとのデータをより頻繁に比較する特定のユースケースがある場合は、少し利点があります.インデックス ページと一致する高速。
欠点は、3 つの個別の int 列を使用すると、SQL Server 側で追加のコーディングに頼ることなく、日付の検証がほぼフロントエンドで行われることです。
はい、3 つの列を、浮動小数点数であるユリウス暦の日付を含む 1 つの列に置き換えることをお勧めします。ドットの前の部分は日を表し、ドットの後の部分はその日の時間を表します。計算は簡単で、ユリウス暦を月/日/年などに簡単に変換することもできます。MS Excel は日付を浮動小数点数として内部的に保存するので、良い仲間になると思います。