はい、承知いたしました。SQLのDATE型の使い方に関する詳細なガイド記事を作成します。指定された要件に従い、約5000語での記述を目指します。

以下が記事の内容です。

SQL DATE型徹底完全ガイド：基礎から応用、データベースごとの違いまで

はじめに：データベースにおける日付の重要性

データベースは、単なるデータを格納する場所ではありません。データは多くの場合、時間的な要素と密接に関連しています。いつ注文されたか、いつ顧客が登録されたか、いつイベントが発生したか、いつデータが最後に更新されたか――これらの情報は、ビジネス分析、レポーティング、データ管理において不可欠です。

例えば、

特定の期間の売上を集計する。
特定の日に誕生日を迎える顧客をリストアップする。
期限切れ間近のタスクを抽出する。
ユーザーの行動履歴を時系列で追跡する。

といった処理は、すべて日付や時刻データがなければ実現できません。

SQLには、このような時間に関わるデータを扱うための様々なデータ型が用意されています。その中でも、最も基本的でありながら頻繁に使用されるのが「DATE」型です。この型は、文字通り「日付」のみを格納するために設計されています。

本記事では、SQLのDATE型に焦点を当て、その基礎から応用、さらには異なるデータベースシステム（RDBMS）間での構文の違いや注意点まで、網羅的に解説します。この記事を読み終える頃には、SQLで日付を扱うことに自信が持てるようになっているでしょう。約5000語にわたる詳細な解説を通じて、DATE型に関するあなたの知識を盤石なものにしましょう。

第1部：DATE型の基礎知識

1.1 SQLにおける日付・時刻関連のデータ型

SQLには、日付や時刻を扱うためのいくつかのデータ型があります。DATE型を理解するためには、これらの関連する型との違いを把握することが重要です。

DATE: 年、月、日のみを格納します。時刻情報は含まれません。
TIME: 時、分、秒（およびオプションでマイクロ秒などの小数部）のみを格納します。日付情報は含まれません。
DATETIME / TIMESTAMP: 年、月、日、時、分、秒（およびオプションで小数部）を格納します。多くの場合、DATETIMEは固定の範囲の値を持ち、タイムゾーン情報は持ちません。TIMESTAMPは、タイムゾーンに関連付けられていたり、エポックからの秒数として格納されたりすることがあります（具体的な挙動はRDBMSによって異なります）。

これらの型の中で、DATE型は最もシンプルで、純粋な日付のみが必要な場合に最適な選択肢です。例えば、人の生年月日や、書類の発効日・有効期限など、時刻情報が不要な場面で利用します。

1.2 DATE型の内部表現とストレージ

DATE型がデータベースの内部でどのように格納されるかは、使用するRDBMSによって異なります。しかし、一般的には日付を効率的に表現するための固定長の数値形式で格納されます。

MySQL: 通常、3バイトを使用し、年、月、日をパックされた形式で格納します。例えば、日付を「日数」として基準日から数えるなどの方法で表現されます。
PostgreSQL: 通常、4バイトを使用し、ある基準日からの日数として格納します。
SQL Server: 3バイトを使用します。1900年1月1日からの日数として格納されます。
Oracle: 通常、7バイトを使用し、世紀、年、月、日、時、分、秒を格納しますが、DATE型が日付のみを扱う場合でも、内部的には時刻情報（通常は午前0時）も保持されます。

これらの内部表現の違いは、通常、SQLクエリを書く上で直接意識する必要はありません。しかし、ストレージサイズを知っておくことは、大量のデータを扱う際のディスク容量の見積もりに役立つことがあります。重要なのは、DATE型が単なる文字列ではなく、データベースが日付として認識し、計算や比較を効率的に行える形式で格納されているということです。

1.3 DATE型を選択する理由

他の日付・時刻型があるにも関わらず、なぜDATE型を選ぶのでしょうか？

シンプルさ: 日付情報のみに特化しており、時刻の考慮が不要なため、データの扱いがシンプルになります。
ストレージ効率: DATETIMEやTIMESTAMPに比べて、通常、少ないストレージ容量で済みます。これは、大規模なテーブルで重要な要素となる場合があります。
意図の明確化: そのカラムが「時刻を含まない純粋な日付」を表していることを明確にできます。これにより、スキーマの可読性が向上します。
比較の容易さ: 日付同士の比較や範囲指定が直感的かつ効率的に行えます。時刻部分の考慮が不要なため、意図しない結果を防ぎやすくなります。

例えば、誕生日を格納するカラムにDATETIME型を使用すると、意図せず時刻情報（例えば、レコードが作成されたときの時刻）が含まれてしまい、比較や集計が複雑になる可能性があります。そのような場合は、迷わずDATE型を選択すべきです。

第2部：テーブル定義とデータの挿入

2.1 テーブル定義におけるDATE型の利用

テーブルのカラムを定義する際に、DATE型を指定します。基本的な構文は以下の通りです。

sql CREATE TABLE テーブル名 ( カラム名1 データ型, カラム名2 DATE, -- ここでDATE型を指定カラム名3 データ型, ... );

例：ユーザーテーブルの作成

ユーザーの登録日と生年月日を格納するテーブルを作成します。

sql CREATE TABLE users ( user_id INT PRIMARY KEY, username VARCHAR(50) NOT NULL, registration_date DATE NOT NULL, -- 登録日は日付のみ birth_date DATE, -- 生年月日は日付のみ email VARCHAR(100) );

この例では、registration_dateとbirth_dateカラムにDATE型を指定しています。NOT NULL制約は、そのカラムがNULL値を許容するかどうかを定義します。登録日は必須としたいためNOT NULLとし、生年月日は任意としたいためNULLを許容するように定義しています。

2.2 デフォルト値の設定

DATEカラムにデフォルト値を設定することも可能です。よく使用されるのは、レコードが挿入された現在の日付をデフォルト値とする場合です。これには、RDBMSが提供する現在日付を取得する関数を使用します。

例：デフォルト値を現在日付に設定（RDBMSごとの違いに注意）

“`sql
— MySQL
CREATE TABLE events_mysql (
event_id INT PRIMARY KEY,
event_name VARCHAR(100) NOT NULL,
event_date DATE DEFAULT ‘2024-01-01’, — 特定の日付をデフォルトに
created_date DATE DEFAULT (CURRENT_DATE) — 現在日付をデフォルトに (カッコが必要な場合と不要な場合がある)
);

— PostgreSQL
CREATE TABLE events_postgres (
event_id INT PRIMARY KEY,
event_name VARCHAR(100) NOT NULL,
event_date DATE DEFAULT ‘2024-01-01’, — 特定の日付をデフォルトに
created_date DATE DEFAULT CURRENT_DATE — 現在日付をデフォルトに (カッコ不要)
);

— SQL Server
CREATE TABLE events_sqlserver (
event_id INT PRIMARY KEY,
event_name VARCHAR(100) NOT NULL,
event_date DATE DEFAULT ‘2024-01-01’, — 特定の日付をデフォルトに
created_date DATE DEFAULT GETDATE() — 現在日付をデフォルトに (GETDATE() はDATETIMEを返すため、DATEカラムでは時刻部分が切り捨てられる)
);

— Oracle
CREATE TABLE events_oracle (
event_id INT PRIMARY KEY,
event_name VARCHAR(100) NOT NULL,
event_date DATE DEFAULT DATE ‘2024-01-01’, — 特定の日付をデフォルトに (DATEキーワードが必要)
created_date DATE DEFAULT SYSDATE — 現在日付をデフォルトに (SYSDATEはDATE型を返す)
);
“`

補足:
* 現在日付を取得する関数はRDBMSによって異なります (CURRENT_DATE, CURDATE(), GETDATE(), SYSDATE)。
* GETDATE() (SQL Server) や SYSDATE (Oracle) は通常、時刻情報を含むデータ型（DATETIMEやDATE型（Oracleの場合））を返しますが、DATEカラムに挿入される際に自動的に日付部分のみが使用されます。
* デフォルト値として特定の日付を指定する場合は、通常 'YYYY-MM-DD' の形式で文字列リテラルを指定します。Oracleの場合は DATE 'YYYY-MM-DD' の構文も一般的です。

2.3 データの挿入

DATEカラムにデータを挿入する際は、主に以下の方法があります。

日付文字列リテラルを使用する: 標準的な 'YYYY-MM-DD' 形式の文字列で日付を指定します。これは最も一般的で推奨される方法です。
現在日付を取得する関数を使用する: レコード挿入時の現在日付を挿入する場合に使用します。
他の日付・時刻データ型からの変換: DATETIMEやTIMESTAMPカラム、あるいはそれらの値から日付部分のみを抽出して挿入します。

例：データの挿入

“`sql
— users テーブルへの挿入
INSERT INTO users (user_id, username, registration_date, birth_date, email)
VALUES (1, ‘Alice’, ‘2023-04-15’, ‘1990-07-21’, ‘[email protected]’);

INSERT INTO users (user_id, username, registration_date, birth_date, email)
VALUES (2, ‘Bob’, CURRENT_DATE, NULL, ‘[email protected]’); — 登録日は今日の日付、生年月日はNULL

INSERT INTO users (user_id, username, registration_date, birth_date, email)
VALUES (3, ‘Charlie’, ‘2024-01-01’, ‘2005-03-10’, ‘[email protected]’);
“`

日付文字列の形式に関する注意点:

ISO 8601標準である 'YYYY-MM-DD' 形式は、RDBMSに依存せず、最も安全で推奨される形式です。しかし、RDBMSによっては 'MM/DD/YYYY' や 'DD-MM-YYYY' のような他の形式も文字列として認識し、自動的にDATE型に変換してくれる場合があります。

しかし、これは非常に危険です！ 例えば、'01/02/2024' という文字列は、環境設定によっては「1月2日」とも「2月1日」とも解釈される可能性があります。また、RDBMSやその設定（言語設定など）によって解釈が変わるため、移植性が低く、意図しないバグの原因となります。

常に 'YYYY-MM-DD' 形式の文字列リテラルを使用するか、データベース固有の日付変換関数（TO_DATEなど）を使用して、文字列から明示的に日付型に変換することを強く推奨します。

例：日付変換関数（RDBMS固有）

“`sql
— Oracle: TO_DATE関数で任意のフォーマットの文字列をDATE型に変換
INSERT INTO users (user_id, username, registration_date)
VALUES (4, ‘David’, TO_DATE(’15-APR-2023′, ‘DD-MON-YYYY’));

— SQL Server: CONVERTまたはCAST関数で文字列をDATE型に変換
INSERT INTO users (user_id, username, registration_date)
VALUES (5, ‘Eve’, CAST(‘20230415’ AS DATE)); — YYYYMMDD形式もSQL Serverではよく使われる

INSERT INTO users (user_id, username, registration_date)
VALUES (6, ‘Frank’, CONVERT(DATE, ’04/15/2023′, 101)); — MM/DD/YYYY 形式 (スタイルコード101)
“`

これらの関数を使用することで、どのような形式の文字列からでも安全にDATE型に変換できます。ただし、RDBMSによって関数名や引数の構文が異なりますので注意が必要です。

第3部：データの取得とフィルタリング

DATE型カラムに格納されたデータは、他のデータ型と同様にSELECT文を使用して取得できます。最も一般的な用途は、特定の日付や日付範囲でデータをフィルタリングすることです。

3.1 基本的なSELECT文

sql SELECT user_id, username, registration_date, birth_date FROM users;

これは、テーブルからすべてのレコードと指定されたカラムを取得します。DATEカラムの値は、通常、データベースの設定に応じた標準的な日付形式（例: YYYY-MM-DD）で表示されます。

3.2 特定の日付でフィルタリングする

厳密に一致する日付でレコードを抽出します。

sql -- 2023年4月15日に登録したユーザーを検索 SELECT user_id, username FROM users WHERE registration_date = '2023-04-15';

ここでも 'YYYY-MM-DD' 形式の文字列リテラルを使用するのが安全です。データベースは内部的にこの文字列をDATE型に変換して比較を行います。

3.3 日付範囲でフィルタリングする

特定の日付範囲内のレコードを抽出することは非常に一般的です。これには主に2つの方法があります。

BETWEEN 演算子を使用する
比較演算子 (>= および <=) を使用する

BETWEEN 演算子:

BETWEEN start_date AND end_date は、start_date から end_date までの両端を含む範囲を指定します。

sql -- 2023年中に登録したユーザーを検索 (2023-01-01 から 2023-12-31 まで) SELECT user_id, username, registration_date FROM users WHERE registration_date BETWEEN '2023-01-01' AND '2023-12-31';

これは簡潔で読みやすい構文です。

比較演算子 (>= および <=):

BETWEEN と同じ結果を得るには、以下のように記述します。

sql -- 2023年中に登録したユーザーを検索 (2023-01-01 から 2023-12-31 まで) SELECT user_id, username, registration_date FROM users WHERE registration_date >= '2023-01-01' AND registration_date <= '2023-12-31';

こちらも明確で、BETWEEN と同様に非常に効率的です。どちらを使用するかは、個人の好みやコーディング規約によりますが、BETWEEN は日付範囲指定の意図がより明確になる傾向があります。

注意：DATETIME/TIMESTAMPカラムとの比較

もしDATE型カラムではなく、DATETIME型やTIMESTAMP型カラムに対して日付範囲を指定する場合、BETWEEN を使う際には注意が必要です。例えば、WHERE datetime_col BETWEEN '2023-01-01' AND '2023-12-31' とすると、'2023-12-31' はその日の午前0時（'2023-12-31 00:00:00'）と解釈されることが多いです。したがって、12月31日中のレコードをすべて含めたい場合は、次のようにする必要があります。

sql -- DATETIME/TIMESTAMPカラムで2023年中のレコードを取得する場合 SELECT ... FROM your_table WHERE datetime_col >= '2023-01-01' AND datetime_col < '2024-01-01'; -- 翌年の最初の日より小さい

このように、BETWEEN を使う場合は終端の日付の「時刻」に注意が必要ですが、>= と < を組み合わせる方法（終端日の翌日の午前0時を < で指定）は、終端日の全時刻を含む確実な方法です。

DATE型カラムの場合は時刻情報がないため、このような複雑さはなく、BETWEEN 'YYYY-MM-DD' AND 'YYYY-MM-DD' または >= 'YYYY-MM-DD' AND <= 'YYYY-MM-DD' で問題ありません。しかし、このDATETIME/TIMESTAMPの挙動は非常に一般的で重要な注意点なので、ここで触れておきました。

3.4 特定の条件を満たす日付をフィルタリングする

特定の日付部分（年、月、日など）に基づいてフィルタリングしたい場合があります。これには、後述する日付関数を利用します。ただし、これらの関数をWHERE句の対象カラムに適用すると、インデックスが利用されなくなる可能性があるため（関数ベースインデックスが定義されていない限り）、パフォーマンスに影響を与える可能性があることに注意が必要です。

例：特定の年に登録したユーザーを検索

“`sql
— 2023年に登録したユーザーを検索 (関数を使用する方法 – 注意！)
SELECT user_id, username, registration_date
FROM users
WHERE YEAR(registration_date) = 2023; — MySQL, SQL Server など

— PostgreSQL, Oracle の場合
SELECT user_id, username, registration_date
FROM users
WHERE EXTRACT(YEAR FROM registration_date) = 2023;
“`

このクエリは機能しますが、registration_dateカラムに通常のB-treeインデックスが貼ってある場合、データベースはテーブル全体をスキャンして各行のregistration_dateに対してYEAR()またはEXTRACT()関数を実行し、その結果を2023と比較する必要があります。これはインデックスを使った高速なシークよりもはるかに遅くなる可能性があります。

インデックスを活用できる代替策:

日付範囲を利用して同じ結果を得る方が、通常はインデックスを効果的に使用でき、パフォーマンスが向上します。

sql -- 2023年に登録したユーザーを検索 (日付範囲を使用する方法 - 推奨) SELECT user_id, username, registration_date FROM users WHERE registration_date >= '2023-01-01' AND registration_date <= '2023-12-31';

あるいは、

sql SELECT user_id, username, registration_date FROM users WHERE registration_date BETWEEN '2023-01-01' AND '2023-12-31';

これらのクエリは、registration_dateカラムのインデックス（存在すれば）を効率的に利用できます。データベースはインデックスを使って、指定された日付範囲に該当するレコードを直接見つけ出すことができます。

したがって、特別な理由がない限り、WHERE句で日付カラムをフィルタリングする際には、日付関数を使うよりも日付範囲指定（>=、<=、BETWEEN）を使用することを強く推奨します。

ただし、抽出した日付部分を表示する（例：SELECT句で YEAR(birth_date) を使う）のは全く問題なく、パフォーマンスに影響しません。

第4部：日付演算 (Date Arithmetic)

SQLのDATE型は、単に日付を格納するだけでなく、日付同士の計算や、日付に一定期間を加算/減算する演算をサポートしています。これは、例えば「注文日から30日後の日付を計算する」とか、「あるイベントから何日経過したかを知る」といったタスクで非常に役立ちます。

日付演算の構文は、RDBMSによって大きく異なります。 ここでは主要なRDBMSでの構文を見ていきましょう。

4.1 日付に日数を加算/減算する

MySQL:

DATE_ADD(date, INTERVAL value unit) または date + INTERVAL value unit
DATE_SUB(date, INTERVAL value unit) または date - INTERVAL value unit
unit には DAY, WEEK, MONTH, YEAR などを指定できます。日数の場合は DAY を使用します。

sql SELECT registration_date, registration_date + INTERVAL 7 DAY AS one_week_after, -- 7日後 registration_date - INTERVAL 30 DAY AS thirty_days_before -- 30日前 FROM users;

PostgreSQL:

date + integer (日数を加算)
date - integer (日数を減算)
date + interval 'value unit' (より柔軟な期間指定)
date - interval 'value unit'

sql SELECT registration_date, registration_date + 7 AS one_week_after, -- 7日後 (日数として加算) registration_date - 30 AS thirty_days_before, -- 30日前 (日数として減算) registration_date + interval '1 week' AS one_week_after_interval, -- 1週間後 registration_date - interval '1 month' AS one_month_before -- 1ヶ月前 FROM users;

SQL Server:

DATEADD(unit, value, date)

sql SELECT registration_date, DATEADD(day, 7, registration_date) AS one_week_after, -- 7日後 DATEADD(day, -30, registration_date) AS thirty_days_before, -- 30日前 DATEADD(week, 1, registration_date) AS one_week_after_dateadd, -- 1週間後 DATEADD(month, -1, registration_date) AS one_month_before -- 1ヶ月前 FROM users;

Oracle:

date + integer (日数を加算)
date - integer (日数を減算)
date + INTERVAL 'value' unit (より柔軟な期間指定)
date - INTERVAL 'value' unit
unit には DAY, MONTH, YEAR などを指定できます。

sql SELECT registration_date, registration_date + 7 AS one_week_after, -- 7日後 (日数として加算) registration_date - 30 AS thirty_days_before, -- 30日前 (日数として減算) registration_date + INTERVAL '7' DAY AS one_week_after_interval, -- 7日後 registration_date - INTERVAL '1' MONTH AS one_month_before -- 1ヶ月前 FROM users;

ご覧のように、同じ「日付に日数を加算する」という操作でも、RDBMSによって構文が大きく異なります。他の単位（週、月、年など）を加算/減算する場合も同様に構文が変わります。

4.2 日付の差を計算する

2つのDATE値間の日数や、その他の期間の差を計算することも可能です。これもRDBMSによって構文が異なります。

MySQL:

DATEDIFF(date1, date2): date1 から date2 を引いた日数を返します (date1 - date2)。
TIMESTAMPDIFF(unit, datetime1, datetime2): より細かい単位（秒、分、時間、日、週、月、四半期、年）での差を計算できます。DATE型に対しても使用可能で、その場合時刻部分は考慮されません。結果は datetime2 - datetime1 です。

sql SELECT birth_date, registration_date, DATEDIFF(registration_date, birth_date) AS days_at_registration, -- 登録時の年齢を日数で計算 TIMESTAMPDIFF(YEAR, birth_date, CURRENT_DATE) AS age_in_years -- 現在の年齢を年で計算 (誕生日が来ていれば正確) FROM users WHERE birth_date IS NOT NULL;

PostgreSQL:

date2 - date1: 2つのDATE値の差は interval 型、または日数を表す integer 型として返されます。
EXTRACT(unit FROM interval): interval 型から特定の単位を抽出します。

sql SELECT birth_date, registration_date, registration_date - birth_date AS diff_interval, -- interval型で差を返す EXTRACT(day FROM registration_date - birth_date) AS days_at_registration, -- 日数を抽出 EXTRACT(year FROM age(CURRENT_DATE, birth_date)) AS age_in_years -- age関数とEXTRACTで年齢を計算 FROM users WHERE birth_date IS NOT NULL;
PostgreSQLの age(timestamp, timestamp) 関数は便利な日付差計算を提供しますが、厳密には誕生日を考慮した年齢計算は少し複雑になる場合があります。

SQL Server:

DATEDIFF(unit, date1, date2): date2 から date1 までの期間を指定した単位で計算します。結果は整数です。

sql SELECT birth_date, registration_date, DATEDIFF(day, birth_date, registration_date) AS days_at_registration, -- 登録時の年齢を日数で計算 DATEDIFF(year, birth_date, GETDATE()) AS age_in_years -- 現在の年齢を年で計算 (これは年の差を計算するだけで、誕生日が来ているかは考慮しない簡易的な方法) FROM users WHERE birth_date IS NOT NULL;
SQL ServerのDATEDIFF(year, date1, date2)は、date2の年からdate1の年を引くだけで、誕生日が来ているかを考慮しません。正確な年齢計算には追加のロジックが必要です。

Oracle:

date2 - date1: 2つのDATE値の差は日数（小数点以下を含む）として返されます。
MONTHS_BETWEEN(date1, date2): 2つの日付間の月数を計算します。
date + numtodsinterval(value, 'unit'): 数値を指定した単位の期間に変換し、日付に加算できます。差を計算する場合は逆算が必要です。

sql SELECT birth_date, registration_date, registration_date - birth_date AS days_at_registration, -- 日数として差を返す (小数点以下を含む可能性あり) TRUNC(MONTHS_BETWEEN(SYSDATE, birth_date) / 12) AS age_in_years -- 月数から年を計算 FROM users WHERE birth_date IS NOT NULL;

4.3 日付演算の応用例

日付演算は、さまざまなレポートや分析に利用できます。

期限管理: WHERE due_date < CURRENT_DATE で期限切れのタスクを抽出。
経過日数: SELECT DATEDIFF(CURRENT_DATE, order_date) AS days_since_order FROM orders で注文からの経過日数を計算。
将来の日付の計算: SELECT invoice_date + INTERVAL 30 DAY AS due_date FROM invoices で請求書の支払期限を計算。
特定の期間のデータ集計: GROUP BYと日付関数/演算を組み合わせて、週ごと、月ごと、年ごとの集計を行う。

日付演算子はWHERE句やHAVING句、さらにはSELECT句やORDER BY句でも利用できます。ただし、WHERE句で演算結果を使ってフィルタリングする場合、演算対象のカラムにインデックスが効きにくくなる可能性がある点に注意が必要です。

第5部：日付関数 (Date Functions)

SQLには、日付の各要素（年、月、日など）を抽出したり、日付のフォーマットを変更したり、特定の日（週の最初の日、月の最終日など）を取得したりするための豊富な日付関数が用意されています。これらの関数も、RDBMSによって提供されるものが異なります。

5.1 日付要素の抽出

日付から年、月、日、曜日などを抽出する関数です。

MySQL:

YEAR(date): 年 (YYYY)
MONTH(date): 月 (1-12)
DAY(date) または DAYOFMONTH(date): 日 (1-31)
WEEK(date): 週番号
DAYOFWEEK(date): 曜日 (1=Sunday, …, 7=Saturday)
DAYOFYEAR(date): 年の初めからの日数 (1-366)
QUARTER(date): 四半期 (1-4)
DAYNAME(date): 曜日の名前 (例: ‘Monday’)
MONTHNAME(date): 月の名前 (例: ‘January’)

sql SELECT registration_date, YEAR(registration_date) AS reg_year, MONTH(registration_date) AS reg_month, DAY(registration_date) AS reg_day, DAYNAME(registration_date) AS reg_weekday FROM users;

PostgreSQL, Oracle (標準SQLのEXTRACT関数):

EXTRACT(unit FROM date): 指定した単位を抽出します。unit には YEAR, MONTH, DAY, DOW (Day Of Week), DOY (Day Of Year), QUARTER, WEEK などを指定します。PostgreSQLのDOWは0=Sundayです。

sql SELECT registration_date, EXTRACT(YEAR FROM registration_date) AS reg_year, EXTRACT(MONTH FROM registration_date) AS reg_month, EXTRACT(DAY FROM registration_date) AS reg_day, EXTRACT(DOW FROM registration_date) AS reg_weekday_num -- PostgreSQL: 0=Sunday FROM users;
OracleのEXTRACTはPostgreSQLと同様ですが、曜日には別の関数も使われます。

SQL Server:

YEAR(date): 年 (YYYY)
MONTH(date): 月 (1-12)
DAY(date): 日 (1-31)
DATEPART(unit, date): 指定した単位を整数で返します。unit には year, month, day, weekday, weekofyear, quarter などを指定します。weekday はSQL Serverの設定によって開始曜日が変わります。
DATENAME(unit, date): 指定した単位の名前を文字列で返します (weekday, month など)。

sql SELECT registration_date, YEAR(registration_date) AS reg_year, MONTH(registration_date) AS reg_month, DAY(registration_date) AS reg_day, DATENAME(weekday, registration_date) AS reg_weekday_name -- 曜日の名前 FROM users;

5.2 現在日付の取得

システム上の現在の日付を取得する関数です。

MySQL: CURDATE(), CURRENT_DATE (どちらも同じ結果を返す)
PostgreSQL: CURRENT_DATE
SQL Server: GETDATE() (DATETIMEを返すので、DATE型として使用する際は日付部分のみが使われる), CURRENT_DATE (SQL Server 2008以降で標準SQLに対応)
Oracle: SYSDATE (DATE型を返す), CURRENT_DATE (セッションタイムゾーン考慮)

sql -- 例: 今日の誕生日リスト SELECT user_id, username FROM users WHERE birth_date = CURRENT_DATE; -- RDBMSに応じて適切な関数を使用

5.3 日付のフォーマット変換

データベースから取得した日付を、表示目的に合わせて特定の文字列形式にフォーマット変換したい場合があります。

MySQL:

DATE_FORMAT(date, format): 日付を特定の書式の文字列に変換します。

sql SELECT registration_date, DATE_FORMAT(registration_date, '%Y/%m/%d') AS formatted_date_ymd, -- 例: 2023/04/15 DATE_FORMAT(registration_date, '%M %d, %Y') AS formatted_date_mdy -- 例: April 15, 2023 FROM users;
%Y, %m, %d, %M などのフォーマットコードはMySQLのリファレンスを参照してください。

PostgreSQL, Oracle:

TO_CHAR(date, format): 日付を特定の書式の文字列に変換します。

sql SELECT registration_date, TO_CHAR(registration_date, 'YYYY/MM/DD') AS formatted_date_ymd, -- 例: 2023/04/15 TO_CHAR(registration_date, 'Month DD, YYYY') AS formatted_date_mdy -- 例: April 15, 2023 (Paddingに注意) FROM users;
PostgreSQLとOracleのフォーマットコードは似ていますが、一部異なります（例: 月の名称はMySQLの%Mに対し、PostgreSQL/OracleはMonthやMONなど）。

SQL Server:

FORMAT(date, format_string) (SQL Server 2012以降): .NET Frameworkのフォーマット文字列を使用できます。
CONVERT(data_type, expression, style): 特定のスタイルコードを使用して日付を文字列に変換します。

sql SELECT registration_date, FORMAT(registration_date, 'yyyy/MM/dd') AS formatted_date_ymd_format, -- 例: 2023/04/15 (SQL Server 2012+) CONVERT(VARCHAR, registration_date, 111) AS formatted_date_ymd_convert -- 例: 2023/04/15 (スタイルコード111) FROM users;
SQL ServerのCONVERT関数は非常に多くのスタイルコードを持っており、様々なフォーマットに対応できます。

5.4 その他の便利な日付関数

RDBMSによっては、さらに便利な日付関連関数を提供しています。

LAST_DAY(date) (MySQL, Oracle): 指定した日付を含む月の最終日を取得します。
DATE_TRUNC(unit, date) (PostgreSQL): 日付を指定した単位（例: 月、年）の開始日（時刻は00:00:00）に切り捨てます。DATE型の場合は日付部分のみが使われます。
TRUNC(date) (Oracle): 日付の時刻部分を切り捨てます（DATE型の場合は時刻は元々00:00:00なので通常は変化なし）。
EOMONTH(date) (SQL Server): 指定した日付を含む月の最終日を取得します。
MAKEDATE(year, dayofyear) (MySQL): 年と年内日数から日付を作成します。

これらの関数は、特定の月の初日や最終日を計算したり、日付を「月」や「年」単位でグループ化したりする際に役立ちます。

第6部：インデックスとパフォーマンス

DATEカラムにインデックスを設定することは、日付による検索やフィルタリングのパフォーマンスを向上させる上で非常に重要です。

6.1 DATEカラムに対するインデックス

DATE型カラムは、他のデータ型（数値、文字列など）と同様にB-treeインデックスの対象とすることができます。

sql CREATE INDEX idx_registration_date ON users (registration_date); CREATE INDEX idx_birth_date ON users (birth_date);

インデックスが適切に設定されていれば、以下のようなクエリは高速に実行されます。

特定の日付での検索: WHERE registration_date = 'YYYY-MM-DD'
日付範囲での検索: WHERE registration_date BETWEEN 'start' AND 'end' または WHERE registration_date >= 'start' AND registration_date <= 'end'
インデックスの先頭部分を使った検索: WHERE registration_date >= 'start'

インデックスはデータのソートされた構造を提供するため、データベースはインデックスツリーを辿ることで、該当する日付のレコードを効率的に見つけ出すことができます。

6.2 WHERE句で関数を使用する際の注意点（SARGable vs Non-SARGable）

第3部で触れたように、WHERE句の対象カラムに対して関数を適用すると、通常はインデックスが利用されなくなります。これは「SARGable (Search Argumentable)」ではない条件と呼ばれます。

例えば、以下のクエリはregistration_dateカラムのインデックスを効果的に利用できません。

sql -- インデックスが効きにくいクエリ (Non-SARGable) SELECT user_id, username FROM users WHERE YEAR(registration_date) = 2023;

データベースは、インデックスを使わずにテーブルの全行を読み込み（フルテーブルスキャン）、各行のregistration_dateに対してYEAR()関数を計算し、結果を2023と比較するという遅い処理を行います。

一方、以下のクエリはSARGableであり、インデックスを効果的に利用できます。

sql -- インデックスが効きやすいクエリ (SARGable) SELECT user_id, username FROM users WHERE registration_date >= '2023-01-01' AND registration_date <= '2023-12-31';

この場合、データベースはインデックスを使って'2023-01-01'から'2023-12-31'までの範囲を効率的にスキャンし、該当する行を直接取得できます。

ベストプラクティス:

日付カラムをWHERE句でフィルタリングする際は、可能な限りカラム自体とリテラル値や他のカラム値を比較する形式にする (column > value, column BETWEEN value1 AND value2 など)。
カラムに関数を適用してフィルタリングしたい場合は、代わりに比較対象の値の方に演算を行い、カラム自体はそのまま比較対象とする形式に変更することを検討する。
- 例: WHERE date_col = CURRENT_DATE + INTERVAL 7 DAY (非推奨) よりも WHERE date_col - INTERVAL 7 DAY = CURRENT_DATE (非推奨 – カラムに演算) よりも WHERE date_col = 'YYYY-MM-DD' (推奨) または WHERE date_col >= CURRENT_DATE AND date_col < CURRENT_DATE + INTERVAL 1 DAY (日付範囲で現在日を指定する場合) のようにする。
- WHERE YEAR(date_col) = 2023 を WHERE date_col >= '2023-01-01' AND date_col <= '2023-12-31' に変換する。
どうしても関数をWHERE句で使いたい場合は、関数ベースインデックス (Function-Based Index) の利用を検討する（一部のRDBMSがサポート）。例えば、PostgreSQLやOracleでは CREATE INDEX idx_year_reg_date ON users (YEAR(registration_date)) のようなインデックスを作成できる場合があります。ただし、これはRDBMSの機能に依存し、管理の手間も増えます。

6.3 NULL値とインデックス

DATEカラムがNULLを許容する場合、NULL値はインデックスに含まれないか、あるいはインデックスの特別なセクションに格納されます（RDBMSによる）。WHERE date_col IS NULL や WHERE date_col IS NOT NULL といった条件での検索効率は、インデックスの種類やRDBMSのバージョンによって異なります。一般的には、NULL値が非常に多いか少ない場合にインデックスが有効な傾向があります。

第7部：NULL値の扱い

DATEカラムがNULLを許容する場合、いくつかの注意点があります。

比較: NULL と任意の値（'YYYY-MM-DD' や他の NULL）との比較は、通常、結果が UNKNOWN となり、WHERE句では偽とみなされます。したがって、WHERE birth_date = '1990-07-21' は、birth_dateがNULLの行を含めません。
NULL値の検索: NULL値を含む行を検索するには、IS NULL または IS NOT NULL を使用する必要があります。
sql SELECT user_id, username FROM users WHERE birth_date IS NULL; -- 生年月日が不明なユーザー SELECT user_id, username FROM users WHERE birth_date IS NOT NULL; -- 生年月日が登録されているユーザー
関数と演算: DATE関数や日付演算にNULL値を渡すと、結果は通常NULLになります。
sql SELECT birth_date, YEAR(birth_date), birth_date + INTERVAL 1 DAY FROM users; -- birth_date が NULL の行は、YEAR(birth_date) も birth_date + INTERVAL 1 DAY も NULL になる
デフォルト値: NULLを許容するカラムにDEFAULT CURRENT_DATEなどを設定した場合、INSERT文でそのカラムに値を指定しないと、デフォルト値（現在日付）が挿入され、NULLにはなりません。明示的にNULLを挿入したい場合は INSERT ... VALUES (..., NULL, ...) と指定する必要があります。

NULLの扱いは、日付データが「存在しない」「不明」「適用不能」といった状態を表す場合に重要です。ビジネスロジックに合わせて、NULLを許容するか、あるいは0000-00-00のような特殊な日付で表現するか（非推奨）、適切に設計する必要があります。NULLを使用するのが最も標準的で推奨される方法です。

第8部：異なるRDBMS間での違いのまとめ

本記事全体を通じて、主要なRDBMS（MySQL, PostgreSQL, SQL Server, Oracle）間でのDATE型に関する構文の違いに触れてきました。ここで改めて、重要な違いをまとめておきましょう。

機能/項目	MySQL	PostgreSQL	SQL Server	Oracle
DATE型	DATE	DATE	DATE	DATE
内部表現（目安）	3 bytes	4 bytes	3 bytes	7 bytes
標準日付形式	‘YYYY-MM-DD’ (推奨)	‘YYYY-MM-DD’ (推奨)	‘YYYY-MM-DD’ (推奨)	‘YYYY-MM-DD’ (推奨)
現在日付関数	`CURDATE()`, `CURRENT_DATE`	`CURRENT_DATE`	`GETDATE()`, `CURRENT_DATE`	`SYSDATE`, `CURRENT_DATE`
日付加算/減算	`date +/- INTERVAL val unit`	`date +/- integer`, `date +/- interval 'val unit'`	`DATEADD(unit, val, date)`	`date +/- integer`, `date +/- INTERVAL 'val' unit`
日付差計算	`DATEDIFF(d1, d2)`, `TIMESTAMPDIFF(unit, d1, d2)`	`d2 - d1`, `EXTRACT(unit FROM interval)`	`DATEDIFF(unit, d1, d2)`	`d2 - d1`, `MONTHS_BETWEEN(d1, d2)`
日付要素抽出	`YEAR`, `MONTH`, `DAY`, `DAYNAME`, etc.	`EXTRACT(unit FROM date)`	`YEAR`, `MONTH`, `DAY`, `DATEPART`, `DATENAME`	`EXTRACT(unit FROM date)`
日付フォーマット	`DATE_FORMAT(date, format)`	`TO_CHAR(date, format)`	`FORMAT(date, format_str)`, `CONVERT(varchar, date, style)`	`TO_CHAR(date, format)`
月の最終日	`LAST_DAY(date)`	なし (日付演算で対応)	`EOMONTH(date)`	`LAST_DAY(date)`
日付の切り捨て	なし	`DATE_TRUNC(unit, date)`	なし (CONVERT等で対応)	`TRUNC(date)`

この表は代表的な関数や構文の比較であり、すべてを網羅しているわけではありませんが、RDBMS間の違いが大きい分野を把握するのに役立ちます。SQLのコードを書く際には、使用しているRDBMSの公式ドキュメントを参照することが不可欠です。

第9部：実用的な応用例

これまで学んだDATE型の使い方、日付演算、日付関数を組み合わせて、実際のシナリオでどのように活用できるかを見ていきましょう。

ここでは、架空の orders テーブルを使用します。

“`sql
CREATE TABLE orders (
order_id INT PRIMARY KEY,
customer_id INT,
order_date DATE NOT NULL, — 注文日
shipped_date DATE, — 出荷日 (未出荷の場合はNULL)
total_amount DECIMAL(10, 2)
);

— サンプルデータ挿入 (RDBMSに合わせてCURRENT_DATEなどを調整)
INSERT INTO orders (order_id, customer_id, order_date, shipped_date, total_amount) VALUES
(1, 101, ‘2024-03-15’, ‘2024-03-17’, 150.00),
(2, 102, ‘2024-03-16’, NULL, 250.50),
(3, 101, ‘2024-03-20’, ‘2024-03-22’, 75.20),
(4, 103, ‘2024-04-01’, ‘2024-04-03’, 300.00),
(5, 102, ‘2024-04-05’, ‘2024-04-08’, 120.00),
(6, 103, ‘2024-04-10’, NULL, 450.00),
(7, 101, CURRENT_DATE, NULL, 99.99); — 今日の注文
“`

例1：特定の月の売上を集計する

2024年3月の総売上を計算します。

sql SELECT SUM(total_amount) AS total_sales FROM orders WHERE order_date >= '2024-03-01' AND order_date <= '2024-03-31'; -- または BETWEEN を使用 -- WHERE order_date BETWEEN '2024-03-01' AND '2024-03-31';

例2：今週の注文を抽出する

現在日付を基準に、今週（月曜日から日曜日など、週の定義はDB設定や関数による）の注文を抽出します。これには現在日付と日付演算が必要です。

“`sql
— MySQL (WEEK関数とYEAR関数を使用する場合)
SELECT order_id, order_date, total_amount
FROM orders
WHERE YEAR(order_date) = YEAR(CURDATE())
AND WEEK(order_date) = WEEK(CURDATE()); — WEEK関数の週の開始曜日設定に注意

— MySQL (日付演算で今週の開始日と終了日を計算する場合 – より確実)
SELECT order_id, order_date, total_amount
FROM orders
WHERE order_date BETWEEN DATE_SUB(CURDATE(), INTERVAL WEEKDAY(CURDATE()) DAY) AND DATE_ADD(DATE_SUB(CURDATE(), INTERVAL WEEKDAY(CURDATE()) DAY), INTERVAL 6 DAY);
— WEEKDAY() は月曜=0, 日曜=6 を返す MySQL 固有関数

— PostgreSQL (DATE_TRUNCを使用する場合)
SELECT order_id, order_date, total_amount
FROM orders
WHERE order_date >= DATE_TRUNC(‘week’, CURRENT_DATE)
AND order_date < DATE_TRUNC(‘week’, CURRENT_DATE) + INTERVAL ‘1 week’;

— SQL Server (日付演算で今週の開始日と終了日を計算する場合)
SELECT order_id, order_date, total_amount
FROM orders
WHERE order_date >= DATEADD(wk, DATEDIFF(wk, 0, GETDATE()), 0)
AND order_date < DATEADD(wk, DATEDIFF(wk, 0, GETDATE()), 0) + 7; — 週の開始日はDB設定に依存

— Oracle (TRUNCと日付演算を使用する場合)
SELECT order_id, order_date, total_amount
FROM orders
WHERE order_date >= TRUNC(SYSDATE, ‘IW’) — ‘IW’ はISO週の開始日(月曜日)
AND order_date < TRUNC(SYSDATE, ‘IW’) + 7;
“`

ご覧のように、「今週」という定義一つをとっても、RDBMSによって書き方が大きく変わります。一般的には、現在日付から日付演算を使って期間の開始日と終了日を計算し、その範囲でフィルタリングする方法が最も柔軟でパフォーマンスも安定しやすいです。

例3：注文から出荷までの日数を計算する

出荷済みの注文について、注文日から出荷日までにかかった日数を計算します。

“`sql
— MySQL, SQL Server, Oracle (基本的に日数の差は数値)
SELECT order_id, order_date, shipped_date,
shipped_date – order_date AS days_to_ship — MySQL, Oracle はそのまま差分計算
— MySQL の DATEDIFF も可: DATEDIFF(shipped_date, order_date) AS days_to_ship_mysql
— SQL Server の DATEDIFF: DATEDIFF(day, order_date, shipped_date) AS days_to_ship_sqlserver
FROM orders
WHERE shipped_date IS NOT NULL;

— PostgreSQL (差分はinterval型なので、EXTRACTで日数に変換)
SELECT order_id, order_date, shipped_date,
EXTRACT(day FROM shipped_date – order_date) AS days_to_ship
FROM orders
WHERE shipped_date IS NOT NULL;
“`

例4：まだ出荷されていない、n日以上前の注文を抽出する

例えば、まだ出荷されておらず、注文日から3日以上経過した注文をリストアップします。

“`sql
— MySQL
SELECT order_id, order_date, total_amount
FROM orders
WHERE shipped_date IS NULL
AND order_date <= DATE_SUB(CURDATE(), INTERVAL 3 DAY); — 今日から3日前以前の注文

— PostgreSQL
SELECT order_id, order_date, total_amount
FROM orders
WHERE shipped_date IS NULL
AND order_date <= CURRENT_DATE – 3; — 今日から3日前以前の注文 (日数減算)

— SQL Server
SELECT order_id, order_date, total_amount
FROM orders
WHERE shipped_date IS NULL
AND order_date <= DATEADD(day, -3, GETDATE()); — 今日から3日前以前の注文

— Oracle
SELECT order_id, order_date, total_amount
FROM orders
WHERE shipped_date IS NULL
AND order_date <= SYSDATE – 3; — 今日から3日前以前の注文 (日数減算)
“`

この例のように、DATEカラムと現在日付、そして日付演算を組み合わせることで、「〇日以内」「〇日以上前」といった相対的な期間でのフィルタリングが可能です。これはビジネス要件で非常に頻繁に発生するパターンです。

例5：月ごとの注文数を集計する

注文日を月単位でグループ化して、各月の注文数をカウントします。

“`sql
— MySQL
SELECT YEAR(order_date) AS order_year,
MONTH(order_date) AS order_month,
COUNT(*) AS order_count
FROM orders
GROUP BY YEAR(order_date), MONTH(order_date)
ORDER BY order_year, order_month;

— PostgreSQL, Oracle
SELECT EXTRACT(YEAR FROM order_date) AS order_year,
EXTRACT(MONTH FROM order_date) AS order_month,
COUNT(*) AS order_count
FROM orders
GROUP BY EXTRACT(YEAR FROM order_date), EXTRACT(MONTH FROM order_date)
ORDER BY order_year, order_month;

— または PostgreSQL の DATE_TRUNC を使用
— SELECT DATE_TRUNC(‘month’, order_date)::DATE AS order_month_start, COUNT(*) AS order_count
— FROM orders
— GROUP BY DATE_TRUNC(‘month’, order_date)::DATE
— ORDER BY order_month_start;

— SQL Server
SELECT YEAR(order_date) AS order_year,
MONTH(order_date) AS order_month,
COUNT(*) AS order_count
FROM orders
GROUP BY YEAR(order_date), MONTH(order_date)
ORDER BY order_year, order_month;

— または SQL Server の DATEFROMPARTS を使用 (より明確に日付としてグループ化する場合 – SQL Server 2012+)
— SELECT DATEFROMPARTS(YEAR(order_date), MONTH(order_date), 1) AS order_month_start, COUNT(*) AS order_count
— FROM orders
— GROUP BY DATEFROMPARTS(YEAR(order_date), MONTH(order_date), 1)
— ORDER BY order_month_start;
`` グループ化で日付関数を使う場合は、SELECTリストとGROUP BY句で同じ関数とカラムを指定する必要があります。パフォーマンス上の理由から、大きなデータセットでこのような月ごとの集計を行う場合は、order_date`カラムにインデックスが貼られていることを確認し、必要に応じて関数ベースインデックスや集計テーブルの利用も検討します。しかし、一般的なレポーティングクエリとしては上記の書き方が標準的です。

第10部：よくある落とし穴とベストプラクティス

DATE型を扱う上で、開発者が陥りやすい落とし穴と、それを回避するためのベストプラクティスをまとめます。

10.1 日付を文字列として格納しない

これは最も重要で、絶対に避けるべき間違いです！ 日付をVARCHARやTEXT型で 'YYYY-MM-DD' や 'MM/DD/YYYY' のような文字列として格納しないでください。

なぜ避けるべきか？

正当性の欠如: '2023-02-30' のような無効な日付も格納できてしまいます。DATE型なら自動的にチェックされます。
ソートの問題: '01-12-2023' と '02-01-2023' を文字列としてソートすると、日付順ではなく辞書順になります。DATE型なら正しくソートされます。
比較の問題: '12/31/2023' < '01/01/2024' は文字列としては偽ですが、日付としては真です。DATE型なら正しく比較できます。
パフォーマンスの低下: 日付計算や範囲検索を行うために、いちいち文字列から日付型に変換する必要があり、インデックスも利用しにくくなります。
可読性の低下: そのカラムが日付であることをデータ型からすぐに判断できません。
国際化の問題: さまざまな日付フォーマットが混在し、解釈が難しくなります。

常に日付は日付/時刻関連のデータ型（DATE, DATETIME, TIMESTAMP）で格納してください。

10.2 日付文字列リテラルの形式に注意する

SQL標準の 'YYYY-MM-DD' 形式を使用するのが最も安全です。他の形式の文字列をINSERTまたはWHERE句で使用する場合、RDBMSやその設定によって解釈が変わり、予期せぬ結果になる可能性があります。

ベストプラクティス:

挿入時: INSERT INTO ... VALUES (..., 'YYYY-MM-DD', ...) または、RDBMS固有の日付変換関数（TO_DATE, STR_TO_DATE, CAST, CONVERTなど）で明示的に日付型に変換してから挿入する。
比較時: WHERE date_col = 'YYYY-MM-DD' または、比較対象の文字列を日付変換関数で明示的に日付型に変換してから比較する。

10.3 タイムゾーンの考慮（DATE型では限定的）

DATE型自体は時刻情報を持たないため、DATETIMEやTIMESTAMPほどタイムゾーンの問題は深刻ではありません。しかし、現在日付を取得する関数（CURRENT_DATE, SYSDATEなど）の挙動は、データベースサーバーの設定やセッションのタイムゾーン設定に影響される場合があります。

特に、CURRENT_DATEはセッションのタイムゾーンを考慮する場合がありますが、SYSDATE (Oracle) や GETDATE() (SQL Server), CURDATE() (MySQL) はサーバーのタイムゾーンを反映することが多いです。複数のタイムゾーンにまたがるシステムの場合、現在日付の解釈に注意が必要です。

ただし、純粋な「日付」としてのみ使う分には、タイムゾーンの違いが日を跨ぐような極端なケース（例: 世界標準時で深夜23時、だがローカルタイムゾーンでは翌日0時）以外では問題になりにくいです。

10.4 DATEとDATETIME/TIMESTAMPの適切な使い分け

日付のみが必要な場合: 誕生日、請求日、有効期限など、時刻が不要なら迷わずDATE型を使用します。ストレージ効率が良く、扱いがシンプルです。
時刻も必要な場合: 注文日時、ログ記録日時、更新日時など、時刻情報が重要な場合はDATETIME型またはTIMESTAMP型を使用します。どちらを選ぶかは、タイムゾーンの扱いや格納範囲などの要件、およびRDBMSの特性によります。

不必要にDATETIME/TIMESTAMPを使うと、ストレージ容量が増え、時刻部分の比較や操作が複雑になる可能性があります。

10.5 WHERE句での日付関数使用によるパフォーマンス問題

第6部で詳しく解説したように、WHERE句の左辺（カラム側）に日付関数を使うと、インデックスが効かなくなりやすいです。可能な限り、日付範囲指定や、比較対象の値の方に演算を行う形に変更して、SARGableな条件にすることが重要です。

10.6 NULL値の挙動を理解する

NULL値が比較や関数、演算でどのように扱われるかを理解しておきましょう。NULL値の検索にはIS NULL / IS NOT NULLを使用します。意図しないNULL値が挿入されないよう、NOT NULL制約やデフォルト値を適切に設定することも重要です。

第11部：より高度なトピック (オプション)

約5000語の要件を満たすため、さらにいくつかの高度なトピックに触れておきます。

11.1 カレンダーテーブルの利用

特定の期間の全ての日付（例えば、過去10年間のすべての日付）や、それに関連する情報（曜日名、週番号、祝日かどうか、会計期間など）を格納した「カレンダーテーブル」を作成することがあります。

sql -- カレンダーテーブルの例 (簡易版) CREATE TABLE calendar ( calendar_date DATE PRIMARY KEY, year SMALLINT NOT NULL, month SMALLINT NOT NULL, day SMALLINT NOT NULL, day_of_week SMALLINT NOT NULL, -- 例: 1=月, 7=日 day_name VARCHAR(10), is_weekend BOOLEAN -- MySQL/PostgreSQL, SQL Server/Oracleでは適切な型に変更 );
このテーブルにあらかじめ全ての日付データとその属性を格納しておくと、以下のようなメリットがあります。

集計の容易さ: カレンダーテーブルを他のテーブル（例: orders）と結合することで、簡単に曜日ごとの集計や月ごとの集計などが行えます。
非活動日の考慮: 売上がゼロだった日など、メインのテーブルに存在しない日付もカレンダーテーブルには存在するた、漏れなく集計できます。
複雑な日付計算の回避: 祝日や会計期間のようなデータベースには組み込まれていない情報を事前に計算しておき、クエリ実行時に複雑な計算をする必要がなくなります。

例えば、「平日のみの売上を計算する」といったクエリは、カレンダーテーブルと結合すれば簡単です。

sql SELECT SUM(o.total_amount) FROM orders o JOIN calendar c ON o.order_date = c.calendar_date WHERE c.is_weekend = FALSE;

カレンダーテーブルの作成には、データベース固有の機能（再帰CTE、日付生成関数など）を利用したり、外部ツールで生成したCSVなどをインポートしたりする方法があります。

11.2 再帰CTEを使った日付系列の生成 (PostgreSQL, SQL Server, Oracleなど)

カレンダーテーブルを使わない場合でも、一時的に日付の連続系列を生成したいことがあります。これには、再帰共通テーブル式 (Recursive Common Table Expression, CTE) が有効です。

例：特定の期間の日付を生成する

sql -- PostgreSQL, SQL Server の例 WITH DateSeries AS ( -- アンカーメンバー (開始日) SELECT CAST('2024-04-01' AS DATE) AS current_date_val UNION ALL -- 再帰メンバー (次の日を計算) SELECT CAST(current_date_val + INTERVAL '1 day' AS DATE) -- PostgreSQL -- SELECT DATEADD(day, 1, current_date_val) -- SQL Server FROM DateSeries WHERE current_date_val < '2024-04-10' -- 終了条件 ) SELECT current_date_val FROM DateSeries; -- SQL Server の場合、再帰の上限に注意 (OPTION (MAXRECURSION 0) を追加することも可能)
OracleではCONNECT BY句も利用可能です。

これらの技術は、特定の期間のデータが「存在しない」場合も含めて集計したい場合（例：売上がなかった日の売上を0として表示するレポート）に役立ちます。生成した日付系列をメインのテーブルとJOIN（通常はLEFT JOIN）することで実現できます。

11.3 特定の期間にまたがるイベントの処理

DATE型だけでは難しい場合もありますが、例えば「ある期間に開始し、別の期間に終了するイベント」のようなデータを扱う際にも日付の比較や範囲指定が重要になります。

例: events テーブルに start_date と end_date がある場合。

sql CREATE TABLE events ( event_id INT PRIMARY KEY, event_name VARCHAR(100), start_date DATE, end_date DATE -- NULLは終了日未定など );

特定の日付に開催中のイベント:
WHERE '2024-05-01' BETWEEN start_date AND end_date
または
WHERE start_date <= '2024-05-01' AND (end_date IS NULL OR end_date >= '2024-05-01')
特定の期間内に開始するイベント:
WHERE start_date BETWEEN '2024-05-01' AND '2024-05-31'
特定の期間内に終了するイベント:
WHERE end_date BETWEEN '2024-05-01' AND '2024-05-31'
特定の期間とオーバーラップするイベント: これは少し複雑ですが、期間A (start_A, end_A) と期間B (start_B, end_B) がオーバーラップする条件は、start_A <= end_B AND end_A >= start_B です（終端日を含む場合）。これを応用して、テーブルのstart_date/end_dateカラムと、指定したい期間（例: ‘2024-05-01’から’2024-05-31’）のstart_B=’2024-05-01′, end_B=’2024-05-31’を使ってフィルタリングします。
WHERE start_date <= '2024-05-31' AND (end_date IS NULL OR end_date >= '2024-05-01')
NULLのend_dateを適切に扱う必要があります。

これらの複雑な日付ロジックも、DATE型の適切な利用と日付演算、NULLの考慮によって実現可能です。

まとめ：DATE型をマスターするために

SQLのDATE型は、データベースで日付情報を扱うための基本的かつ非常に強力なツールです。本ガイドでは、その定義からデータの挿入、取得、フィルタリング、日付演算、日付関数、インデックス、NULLの扱い、RDBMSごとの違い、そして実践的な応用例まで、幅広く掘り下げてきました。

DATE型を効果的に使用するための最も重要なポイントは以下の通りです。

日付は必ず日付型で格納する: 文字列として格納するのは避けましょう。
標準形式 'YYYY-MM-DD' を基本とする: 異なるRDBMS間での移植性を高め、解釈の曖昧さを排除できます。
日付演算と関数はRDBMS固有の構文を理解する: 加算/減算、差の計算、要素抽出、フォーマット変換など、目的の操作に対応する関数や演算子を、使用するデータベースに合わせて正しく使い分けましょう。
WHERE句での日付関数利用には注意する: パフォーマンスの観点から、可能な限り日付範囲指定(BETWEEN, >=, <=) によるフィルタリングを優先しましょう。
NULLの扱いを明確にする: 日付が存在しない場合のビジネスロジックを考慮し、NULLの挙動を理解しておきましょう。

約5000語にわたるこのガイドが、あなたのSQLにおけるDATE型の理解を深め、日々の開発やデータ分析に役立つことを願っています。データベースの時間を操る力を手に入れ、より複雑で価値のあるクエリを作成できるようになりましょう。

SQL DATE型 徹底完全ガイド：基礎から応用、データベースごとの違いまで

はじめに：データベースにおける日付の重要性

第1部：DATE型の基礎知識

1.1 SQLにおける日付・時刻関連のデータ型

1.2 DATE型の内部表現とストレージ

1.3 DATE型を選択する理由

第2部：テーブル定義とデータの挿入

2.1 テーブル定義におけるDATE型の利用

2.2 デフォルト値の設定

2.3 データの挿入

第3部：データの取得とフィルタリング

3.1 基本的なSELECT文

3.2 特定の日付でフィルタリングする

3.3 日付範囲でフィルタリングする

3.4 特定の条件を満たす日付をフィルタリングする

第4部：日付演算 (Date Arithmetic)

4.1 日付に日数を加算/減算する

4.2 日付の差を計算する

4.3 日付演算の応用例

第5部：日付関数 (Date Functions)

5.1 日付要素の抽出

5.2 現在日付の取得

5.3 日付のフォーマット変換

5.4 その他の便利な日付関数

第6部：インデックスとパフォーマンス

6.1 DATEカラムに対するインデックス

6.2 WHERE句で関数を使用する際の注意点（SARGable vs Non-SARGable）

6.3 NULL値とインデックス

第7部：NULL値の扱い

第8部：異なるRDBMS間での違いのまとめ

第9部：実用的な応用例

例1：特定の月の売上を集計する

例2：今週の注文を抽出する

例3：注文から出荷までの日数を計算する

例4：まだ出荷されていない、n日以上前の注文を抽出する

例5：月ごとの注文数を集計する

第10部：よくある落とし穴とベストプラクティス

10.1 日付を文字列として格納しない

10.2 日付文字列リテラルの形式に注意する

10.3 タイムゾーンの考慮（DATE型では限定的）

10.4 DATEとDATETIME/TIMESTAMPの適切な使い分け

10.5 WHERE句での日付関数使用によるパフォーマンス問題

10.6 NULL値の挙動を理解する

第11部：より高度なトピック (オプション)

11.1 カレンダーテーブルの利用

11.2 再帰CTEを使った日付系列の生成 (PostgreSQL, SQL Server, Oracleなど)

11.3 特定の期間にまたがるイベントの処理

まとめ：DATE型をマスターするために

コメントする 返信をキャンセル

SQL DATE型徹底完全ガイド：基礎から応用、データベースごとの違いまで

コメントする返信をキャンセル