2nd/10_Wiki/Topic_Programming/Coding/DB_Bitemporal_Data.md

id, title, category, status, source_trust_level, verification_status, created_at, updated_at, tags, tech_stack, applied_in, aliases

id	title	category	status	source_trust_level	verification_status	created_at	updated_at	tags	tech_stack	applied_in	aliases
db-bitemporal-data	Bitemporal Data — valid time + transaction time	Coding	draft	B	conceptual	2026-05-09	2026-05-09	database time vibe-coding	language applicable_to SQL Database		bitemporal valid time transaction time system time SCD slowly changing dimension history

Bitemporal Data

"이 fact 가 valid 한 기간" + "이 fact 가 DB 에 있던 기간". Bitemporal = 둘 다. 회계 / 의료 / legal 가 필수. SCD (Slowly Changing Dimension) 의 generalization.

📖 핵심 개념

• Valid time (effective): 현실 의 fact 시점.
• Transaction time (system): DB 안 시점.
• 둘 다 = bitemporal.
• "내가 1주 전에 알았던 사실 가 무엇" 가능.

💻 코드 패턴

일반 (no time)

CREATE TABLE customers (
  id INT PRIMARY KEY,
  name VARCHAR,
  address VARCHAR
);

UPDATE customers SET address = 'New' WHERE id = 1;
-- → 옛 address 잃음.

Valid time (effective from / to)

CREATE TABLE customers (
  id INT,
  name VARCHAR,
  address VARCHAR,
  valid_from DATE NOT NULL,
  valid_to DATE NOT NULL DEFAULT '9999-12-31',
  PRIMARY KEY (id, valid_from)
);

-- 변경 시
UPDATE customers SET valid_to = '2026-05-09' WHERE id = 1 AND valid_to = '9999-12-31';
INSERT INTO customers VALUES (1, 'Alice', 'New', '2026-05-09', '9999-12-31');

-- "2025-01-01 의 address?"
SELECT address FROM customers
WHERE id = 1 AND valid_from <= '2025-01-01' AND valid_to > '2025-01-01';

→ SCD Type 2.

Transaction time (system)

CREATE TABLE customers (
  id INT,
  name VARCHAR,
  sys_from TIMESTAMP NOT NULL,
  sys_to TIMESTAMP NOT NULL DEFAULT '9999-12-31',
  PRIMARY KEY (id, sys_from)
);

-- "1주 전 DB 에 있던 record?"
SELECT * FROM customers
WHERE id = 1 AND sys_from <= NOW() - INTERVAL '1 week'
  AND sys_to > NOW() - INTERVAL '1 week';

→ "내가 어제 본 거" — even if data 가 retro 변경.

Bitemporal (둘 다)

CREATE TABLE policies (
  policy_id INT,
  premium DECIMAL,
  
  valid_from DATE,    -- 현실 effective
  valid_to DATE DEFAULT '9999-12-31',
  
  sys_from TIMESTAMP,  -- DB transaction
  sys_to TIMESTAMP DEFAULT '9999-12-31',
  
  PRIMARY KEY (policy_id, valid_from, sys_from)
);

Insert (bitemporal)

-- 새 policy
INSERT INTO policies (policy_id, premium, valid_from, valid_to, sys_from, sys_to)
VALUES (1, 100, '2026-01-01', '9999-12-31', NOW(), '9999-12-31');

Update (premium 가 retroactive 변경)

-- 2026-05-09 가 발견: 2026-01-01 부터 premium 가 110 였다 (오타).

-- 1. 옛 row close
UPDATE policies SET sys_to = NOW()
WHERE policy_id = 1 AND sys_to = '9999-12-31';

-- 2. 새 row (valid 가 1월 1일 부터)
INSERT INTO policies VALUES (1, 110, '2026-01-01', '9999-12-31', NOW(), '9999-12-31');

→ "이 시점 에 우리 가 아는 premium" 가 query 가능.

Query: As-of (valid + system)

-- "2026-03-01 시점 의 policy. 1주 전 DB 의 view."
SELECT premium FROM policies
WHERE policy_id = 1
  AND valid_from <= '2026-03-01' AND valid_to > '2026-03-01'
  AND sys_from <= NOW() - INTERVAL '1 week' AND sys_to > NOW() - INTERVAL '1 week';

→ 4 가지 query 가능:

• 현재 valid + 현재 system (default)
• 과거 valid + 현재 system (history)
• 현재 valid + 과거 system ("when did we know?")
• 과거 valid + 과거 system (full audit)

SQL:2011 Temporal

-- Postgres + extension (BTRIM 또는 system-versioned tables 가 옵션)
CREATE TABLE customers (...) WITH SYSTEM VERSIONING;

SELECT * FROM customers FOR SYSTEM_TIME AS OF TIMESTAMP '2026-05-01';

→ MariaDB / SQL Server / IBM DB2 가 native 지원.

Use case: 보험

2026-01-01: Policy 시작, premium $100.
2026-03-01: Customer 가 새 car (premium $120).
2026-04-01: 발견 - 2026-01-01 부터 premium $110 였어야 함.

쿼리:
- "2026-02-15 의 premium" = $100 ($110 retroactive 적용 안 했을 시 본 거).
- "2026-02-15 의 premium (현재 truth)" = $110.

→ 보험 / regulatory 가 "we knew on date X" 답 필요.

Use case: 회계

"2026-Q1 매출 = ?"

- Q1 끝날 시점 답 = $1M.
- 4월 의 retroactive correction 후 답 = $1.05M.

→ Audit: 우리 가 Q1 close 때 본 = $1M.
정정 후 = $1.05M.
둘 다 record 유지.

Pitfall: complexity

Bitemporal 가 어려움.
- 매 update = 2-3 row
- Index 가 복잡 (composite)
- Query 가 복잡

→ 진짜 필요할 때 만.
대부분 = SCD Type 2 (valid time 만) 충분.

Implementation: trigger

CREATE OR REPLACE FUNCTION close_old_row() RETURNS TRIGGER AS $$
BEGIN
  UPDATE policies SET sys_to = NOW()
  WHERE policy_id = NEW.policy_id AND valid_from = NEW.valid_from AND sys_to = '9999-12-31';
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER policy_versioning BEFORE INSERT ON policies
FOR EACH ROW EXECUTE FUNCTION close_old_row();

XTDB (bitemporal native)

(xt/submit-tx node
  [[::xt/put {:xt/id :alice :address "New"}
    #inst "2026-05-09"]])  ; valid time

(xt/q (xt/db node #inst "2026-05-08")
  '{:find [?addr] :where [[:alice :address ?addr]]})
; ↑ as-of yesterday

→ Bitemporal first-class.

Datomic (similar)

(d/q '[:find ?addr
       :where [?e :customer/address ?addr]]
     (d/as-of db tx-id))

→ Immutable + time travel.

Snapshot tables (simpler alternative)

-- 매일 entire DB snapshot
CREATE TABLE customers_snapshot_2026_05_09 AS SELECT * FROM customers;

-- "2026-05-09 의 truth"
SELECT * FROM customers_snapshot_2026_05_09;

→ Storage 큼, query simple.

Event sourcing (related)

Event log (append-only) → state.
"2026-05-09 시점 의 state" = event log replay until then.

→ Bitemporal 의 different angle.

→ Backend_Event_Sourcing.

Audit log (simpler)

CREATE TABLE customer_audit (
  audit_id BIGSERIAL,
  customer_id INT,
  changed_at TIMESTAMP,
  old_data JSONB,
  new_data JSONB
);

-- Trigger 가 매 변경 추가

→ Full bitemporal 가 X. "언제 무엇 변경" 만.

When 진짜 bitemporal?

✓ Insurance (regulatory)
✓ Banking / accounting
✓ Healthcare (EHR — patient history vs DB record)
✓ Legal (contracts vs amendments)
✓ ERP (price catalog history)

✗ 일반 web app
✗ E-commerce
✗ Internal tool

→ "내가 X 시점 에 알았던 거?" 가 비즈니스 질문 일 때 만.

Performance

Composite index:
CREATE INDEX ON policies (policy_id, valid_from, valid_to, sys_from, sys_to);

→ Range query 빠름.
Storage 가 일반 의 N x (N = 평균 history depth).

🤔 의사결정 기준

상황	추천
일반 web	No history
Audit log 필요	Audit table / trigger
현재 + 과거 valid	SCD Type 2 (valid time only)
회계 / 보험 / 법	Full bitemporal
Event-driven	Event sourcing
Functional / immutable	Datomic / XTDB
Ad-hoc snapshot	Daily backup

❌ 안티패턴

• Bitemporal 없이 retroactive correction: 옛 truth 잃음.
• Soft delete 만 + history 없음: 변경 추적 안 됨.
• 모든 table 가 bitemporal: complexity.
• Index 없이: query 가 full scan.
• Trigger error → silent: data corrupt.
• 9999-12-31 가 magic value: NULL 보다 좋지만 명시 필요.

🤖 LLM 활용 힌트

• Bitemporal 진짜 필요 = 회계 / 법 / 의료.
• 대부분 = valid time (SCD Type 2) 충분.
• XTDB / Datomic 가 native 지원.
• Audit log 가 cheap alternative.

🔗 관련 문서

• DB_Audit_Log_Patterns
• Backend_Event_Sourcing
• DB_Soft_Delete_Patterns