7.1 概要と選択基準

時刻を持つデータをすべて同じテーブルに保存する必要はありません。 定期的に測定した温度と「デバイスが再接続した」というイベントでは、分析方法が異なります。 LOGを選ぶときは、時間カラムの有無より、1行が何を表すかを先に考えてください。

LOGテーブルの特性

アプリケーションエラー、セキュリティ機器の遮断記録、処理の開始・終了履歴など、イベントを1件ずつ追加するデータにLOGが適しています。 ユーザーカラムに加えて_arrival_timeが自動的に作成され、時間範囲条件とメッセージ検索を併用できます。

次の例で、イベント発生時刻と入力時刻の違いを確認します。

CREATE LOG TABLE ch7_overview (
    event_time DATETIME,
    device     VARCHAR(32),
    message    VARCHAR(128)
);

INSERT INTO ch7_overview VALUES (
    TO_DATE('2026-01-01 10:00:00', 'YYYY-MM-DD HH24:MI:SS'),
    'DEV-01', 'connection restored'
);

SELECT _arrival_time, event_time, device, message FROM ch7_overview;

DROP TABLE ch7_overview;

1行が返されます。event_timeは例に指定した固定時刻、_arrival_timeは今回の入力で自動的に決まった時刻です。 したがって、実行日が変わってもevent_timeは変わりません。 明示的な入力と補正規則については時間モデルで説明します。

選択基準

「過去1時間のエラー」「このIPアドレスからのリクエスト」「timeoutを含むメッセージ」を頻繁に検索し、 保存済みの行を更新する必要がない場合は、まずLOGを検討してください。 継続入力にはAppend API、初期データやファイル群にはロードツールを使用できます。

入力後に更新できないことだけで、監査データの改ざん防止が保証されるわけではありません。 削除権限、アクセス制御、保持ポリシー、バックアップは別途設計する必要があります。

再送には注意が必要です。同じイベントを再送すると、別の行として保存される場合があります。 LOGにはPRIMARY KEY・UNIQUE制約がないため、自動的な重複排除は期待できません。 元のイベントIDを保持し、収集段階で再試行と重複処理のポリシーを定めてください。

他のテーブルとの比較

LOGは一般的なUPDATEと任意条件のDELETE WHEREをサポートしていません。 訂正イベントを追加する設計は可能ですが、元のIDと訂正理由を保存し、 検索時にどの訂正を反映するかをアプリケーションで決める必要があります。 更新が日常的に発生する業務では、最初から別のテーブルを使うほうが明確です。

設計基準

分析に必要なのが発生時刻か収集時刻かを、まず区別します。 続いて、デバイス・重要度・IPなど、頻繁に使用する条件を決めてください。 これらの値は毎回原文から切り出すより、別カラムに格納するとクエリを理解・管理しやすくなります。 保持期間もこの段階で決めてください。入力方法だけを用意して削除を後回しにすると、ディスク使用量が増え続けます。

次のスキーマ設計では、これらの観点を実際のカラムに反映します。 選択に迷う場合は、代表的なイベント数件と頻繁に使用するクエリを並べて比較してください。