關聯式資料庫中，資料組織形式不僅有傳統的「橫向表」(寬表)，還有「縱向表」——即實體-屬性-值 (Entity-Attribute-Value, EAV) 模型。兩種模式各有優劣，本文以 Oracle 為例 (邏輯通用於所有 RDBMS)，透過實例對比、查詢複雜度分析、優缺點總結與適用場景矩陣，助您做出正確架構決策。
TABLE HR (橫向)
EMP_ID | NAME | GENDER | DEPT | SALARY
-------|-------|--------|---------|-------
1 | Alice | 女 | HR | 60000
2 | Bob | 男 | IT | 80000
3 | Carol | 女 | FINANCE | 75000
SELECT * FROM hr WHERE gender = '男'TABLE VR (縱向)
ID | ATTR_KEY | ATTR_VALUE
---|------------|-----------
1 | NAME | Alice
1 | GENDER | 女
1 | DEPT | HR
1 | SALARY | 60000
2 | NAME | Bob
2 | GENDER | 男
...
ID (PK)、ATTR_KEY、ATTR_VALUEALTER TABLE、無鎖表、無應用重啟。ENTITY_TYPE 或分組欄位區隔。| 維度 | 問題描述 | 影響 |
|---|---|---|
| 資料完整性 | 無法在資料庫層強制 NOT NULL、CHECK、FK、資料類型 (ATTR_VALUE 通常 VARCHAR2) | 業務邏輯外移至應用層，易產生髒資料 |
| 查詢複雜度 | 單一實體查詢需多次自我連接 (Self-Join) 或 PIVOT | SQL 難寫、難讀、優化器難估算基數，效能差 |
| 報表整合 | 主流 BI 工具 (OBIEE, Tableau, PowerBI) 原生不支援 EAV | 需建立視圖/物化視圖/ETL 轉寬表，增加維護成本 |
| 索引效能 | 複合索引 (ATTR_KEY, ATTR_VALUE) 選擇度低，全表掃描風險高 |
大資料量下查詢緩慢 |
| 資料一致性 | 同義詞問題：不同使用者輸入「公司」vs「企業」儲存同一語義 | 需建立主檔/字碼表管控 Key，增加複雜度 |
| 大物件支援 | 難以儲存 BLOB/CLOB/XML/JSON 等複雜類型 | 功能受限 |
需求：查詢所有男性員工
-- 橫向表：單表掃描，索引可用
SELECT * FROM hr WHERE gender = '男';
-- 縱向表：需自連接或子查詢
SELECT v1.id, v1.attr_value AS name, v2.attr_value AS dept
FROM vr v1
JOIN vr v2 ON v1.id = v2.id AND v2.attr_key = 'DEPT'
WHERE v1.attr_key = 'GENDER' AND v1.attr_value = '男';
-- 更多屬性 = 更多 JOIN
引入 GROUP_ID 或 ENTITY_TYPE 欄位，支援同一 ID 下多個邏輯實體群組：
ID | GROUP_ID | ATTR_KEY | ATTR_VALUE
---|----------|----------|-----------
1 | 100 | NAME | Alice
1 | 100 | ROLE | MANAGER
1 | 200 | NAME | Alice
1 | 200 | ROLE | TRAINER
便於報表按群組分頁/分區，但進一步增加查詢維度。
| 場景特徵 | 推薦模式 | 理由 |
|---|---|---|
| 屬性固定、高頻查詢、需強一致性、BI 直連 | 橫向表 (正規化/星狀) | 效能、工具相容、資料品質最佳 |
| 屬性高度動態、使用者自訂欄位、稀疏矩陣 | 縱向表 (EAV) | Schema 演進靈活，儲存效率高 |
| 核心屬性固定 + 少量擴充屬性 | 混合模式：核心寬表 + 擴充 EAV 表 | 兼顧效能與彈性，主流電商/CRM 採用 |
| 文檔型資料、結構多變、需全文檢索 | JSON/XML 欄位 (12c+ JSON) / 文檔資料庫 | 半結構化原生支援，避免 EAV 缺點 |
ATTR_DEFINITION 主檔管控 Key/類型/驗證規則，並提供 PIVOT VIEW / 物化視圖供報表層使用。JSON 欄位、XMLTYPE、PostgreSQL JSONB、MongoDB 等原生半結構化儲存，多數場景下優於手工 EAV。EXPLAIN PLAN / SQL TRACE，驗證 EAV 查詢是否達標。縱向表 (EAV) 是把「雙刃劍」：用對場景是靈活神器，用錯地方是效能地獄。架構師的智慧在於——識別業務的「變與不變」，將核心穩定的寬表化，將邊緣多變的 EAV 化，並在兩層間建立清晰的同步與治理機制。
