可以把所有的junction Table 整合成一個泛用table?

永輝查帳系統資料庫設計參考資料

我們可以把所有的junction Table 整合成一個table 嗎？

理論上可以整合成一張「泛用關聯表」，但不建議全部都整合。
最佳做法是混合式：高頻＆核心關聯保留專用 junction，少量、臨時、跨模組的關聯用泛用表補位。

---

為什麼不建議「全部合一」

缺點（很重要）

• 失去外鍵約束：單一表無法對不同目標表同時做嚴格 FK（多型關聯），容易出現「指到不存在的ID」。
• 無法精準 ON DELETE CASCADE：無法跟隨來源刪除自動清理，只能靠 trigger/批次清理。
• 查詢複雜 & 效能差：條件需要帶 left_type/right_type，索引組合變多、計劃器較難優化。
• 商業規則難落地：像「同一年度、同科目、同對象僅允許一筆」這類唯一性約束很難在單表以 DB 級 constraint 表達。
• 審計可讀性下降：專用表名稱本身就是語意（workpaper_documents 一看就懂），合一後需靠欄位解讀。

什麼時候可整併？

• 低頻跨模組連結，種類多但每種筆數少。
• 快速 PoC/原型階段，想降低 schema 變更成本。
• 已經有嚴格的應用層檢核與週期性資料清理機制。

---

混合式建議（實務最穩）

• 保留專用 junction（建議保留）
  workpaper_documents、confirmation_documents、workpaper_findings、risk_workpapers、risk_procedures、user_roles、role_permissions、engagement_members
  （高頻、約束清楚、報表多）
• **新增一張「泛用關聯表」**處理零星/跨模組關聯
  例如把「某 Finding 臨時掛到某 Control 的特定段落」這類少見關聯放到泛用表。

---

若一定要整合：泛用關聯表設計（建議欄位）

• id
• left_type (文字/enum：’workpaper’/’confirmation’/’finding’/’document’/’risk’/’procedure’/…)
• left_id
• right_type
• right_id
• relation (語意/角色：’evidence’/’supporting’/’primary’/’related’/’owner’ …)
• context_json (可選：期間/錨點/頁碼/Excel 範圍/備註)
• valid_from / valid_to (可選：生效區間)
• created_at / created_by

索引與唯一性

• 索引：(left_type,left_id)、(right_type,right_id)、(left_type,left_id,relation)、(right_type,right_id,relation)
• 唯一鍵（依需要）：UNIQUE(left_type,left_id,right_type,right_id,relation)

資料完整性（很關鍵）

• 無法用 FK？→ 用 Trigger 驗證 *_id 是否存在於對應表。
• 或用 分割表/分區表：依 relation 或 left_type/right_type 作分區，部分子分區可掛 FK。
• 再提供 VIEW 模擬專用表介面（方便報表與相容舊 SQL）。

---

比較表

方案	優點	缺點	適用情境
專用 junction	強約束、好查詢、語意清楚、易做唯一性	表多、演進需加表	高頻核心關聯
泛用一表	schema 彈性、改版快	無 FK、查詢與索引複雜、易髒資料	低頻跨模組連結
混合式（建議）	兩者取長補短	維運較複雜	中大型審計系統

---

落地建議（給工程隊）

1. 先保留專用 junction（上述清單）。
2. 新增 object_links（泛用表）處理少見/臨時連結。
3. 在 object_links 上實作：
   • 觸發器：動態驗證 *_id 存在性；清理孤兒資料。
   • 索引策略：依實際 query pattern 加 composite index。
   • 只讀 VIEW：提供「像專用表一樣的」查詢介面。
4. 設計層面在 API/服務層 隱藏差異：呼叫端不用在意是專用表或泛用表。
5. 監控：定期報表掃出 未知類型、無對應主檔、重複關聯。

---

總結

• 可以合併，但不建議全部。
• 用「專用 + 泛用」的混合式，既保留資料完整性與效能，又有擴充彈性。
• 若後續需要，我可以把 object_links 的精簡 SQL、驗證 trigger 範例與對應 VIEW 一次給到您的現有 schema。

專用Junction Table , 或泛用junction Table 的優缺點？

專用 Junction Table 與 泛用（通用）Junction Table 的優缺點與適用情境一次講清楚，最後附上決策建議與混合式做法。

---

專用 Junction Table

例：workpaper_documents、confirmation_documents）

優點

• 資料完整性高：可以對兩端做嚴格外鍵、ON DELETE CASCADE、UNIQUE 組合鍵（如 UNIQUE(workpaper_id, document_id, role)）。
• 查詢簡單、性能好：SQL 結構固定、索引好設計，最佳化器容易命中（少用 OR/CASE）。
• 語意清楚：看表名就懂關聯語意；報表、權限、審計追蹤較直觀。
• 業務規則可落在 DB 層：如「同一年度同一 TB 行只能對應一封函證」能直接用約束表達。
• 易做級聯與刪除安全：父表刪除時，關聯自動清掉，不留孤兒。

缺點

• 表變多：每新增一種關聯就要開一張表，Schema 較「重」。
• 需求變動要改 Schema：新關聯型態要發版（DDL、遷移）。
• 跨模組少量臨時關聯 額外開表顯得成本高。

適用

• 高頻關聯、資料量大、需要嚴格約束與可審計性（底稿↔附件、函證↔附件、底稿↔議題、角色↔權限、使用者↔角色…）。
• 有明確商業規則、需要 DB 層保護與報表長期穩定的關係。

---

泛用（通用）Junction Table

（例：object_links，欄位 left_type/left_id/right_type/right_id/relation）

優點

• 彈性超高：新增任意關聯不需改 Schema（只加資料列）。
• 開發快、PoC 友善：初期不確定連哪些東西時很好用。
• 跨模組零星關聯 成本低：一次性或臨時性鏈結不必開新表。

缺點

• 難以做外鍵：多型關聯無法直接掛 FK → 容易出現髒資料；需靠 Trigger/應用層檢核。
• 查詢與索引較複雜：常帶 left_type/right_type/relation 條件，索引組合多，性能調校成本高。
• 無法用 DB 級唯一性/商業規則：像「同對象+同科目不可重複」很難在單一通用表用約束表達。
• ON DELETE CASCADE 不好做：需用觸發器或批次清理。
• 可讀性差：語意需靠欄位值判讀，對新同仁與稽核者不直觀。

適用

• 低頻、臨時、跨模組的特殊鏈結（例如偶爾把某 Finding 掛到某 Control 的特定段落）。
• 探索期或快速原型，還沒定案要不要做成「專用關聯」。

---

決策速查表

判斷問題	建議
關聯是否高頻、資料量大、需嚴格 FK/唯一性/級聯？	專用 Junction
報表很多、審計可讀性要高（看表名懂語意）？	專用 Junction
只是零星臨時鏈結、跨模組且難以預見？	泛用 Junction
目前在 PoC/探索期、需求變動大？	先用 泛用，穩定後落地成 專用
需要同時滿足嚴格規則與偶發關聯？	混合式（核心專用 + 泛用補位）

---

混合式最佳實務（推薦）

1. 核心關聯用專用表
   • workpaper_documents、confirmation_documents、workpaper_findings、risk_workpapers、risk_procedures、user_roles、role_permissions、engagement_members …
   • 放 DB 級約束（FK、UNIQUE、CHECK）、索引與 ON DELETE CASCADE。
2. 新增 1 張泛用關聯 object_links（只處理零星、難預測的跨模組關聯）
   • 欄位：id, left_type, left_id, right_type, right_id, relation, context_json, created_at, created_by
   • 索引：(left_type,left_id)、(right_type,right_id)、(left_type,left_id,relation)…
   • Trigger：在寫入/刪除時檢核目標是否存在，並清理孤兒連結。
   • VIEW：對常用查詢包裝成視圖，降低使用門檻。
3. 治理與遷移
   • 以使用量為準：當某種 relation 在 object_links 穩定且變多 → 升級為專用表。
   • 建監控報表：列出無效 ID、重覆關聯、未知 relation。
   • API 層隱藏差異：呼叫端不用知道用的是專用還是泛用。

---

簡短結論

• 專用表 = 規範、性能、可稽核；
• 泛用表 = 彈性、快速、低前置成本；
• 混合式 = 兩者取長補短：核心穩、邊緣靈活。

若您要，我可以把 object_links 的精簡 SQL + 觸發器樣板 + 常用 VIEW 直接補進您目前的 schema。

永輝查帳系統資料庫設計參考資料

接洽我們：

永輝啟佳聯合會計師事務所- EvershineCPA.tpe
臺灣永輝協同網路服務股份有限公司- EvershineBPO.tpe
永輝專利師事務所 – EvershineIPO.tpe
臺北市長春路378號6F 靠近長春路與復興北路交叉口
捷運文湖線與松山線交口 南京復興站,兄弟大飯店附近
接洽人:
陳中成 首席合夥人/會計師/專利師
Mobile: +886-933920199    
Office: +886-2-27170515 E100    
Skype: daleccchen
Wechat ID: evershiinecpa | Line ID:evershinecpa
Linkedin address:Dale Chen Linkedin    
E-mail: dalechen@evershinecpa.com

Evershine在以下城市擁有100%的附屬公司：

永輝總部、臺北永輝、廈門永輝、北京永輝、上海那靈、深圳常新、紐約永輝、加州永輝、德州永輝、鳳凰城永輝、東京永輝、首爾永輝、河內永輝、越南胡志明、曼谷永輝、新加坡永輝、吉隆玻永輝、雅加達永輝、馬尼拉永輝、墨爾本永輝、澳洲雪梨、孟加拉永輝、新德里永輝、印度孟買、杜拜永輝、法蘭克福永輝、巴黎永輝、倫敦永輝、荷蘭永輝、西班牙永輝、義大利永輝、羅馬尼亞永輝、多倫多永輝、墨西哥永輝。
其他已提供中文化服務城市：
邁阿密、亞特蘭大、俄克拉荷馬、密歇根、西雅圖、特拉華；
柏林; 斯圖加特;布拉格；布加勒斯特；班加羅爾；泗水；
高雄、香港、深圳、東關、廣州、清遠、永康、杭州、蘇州、崑山、南京、重慶、許昌、青島、天津。
永輝潛在可服務城市 (2個月籌備期)：
我們為IAPA會員所,總部在倫敦，全球300個會員所，員工約1萬人。
我們為LEA會員所,總部在美國芝加哥，全球600個會員所，員工約2萬8千人。
Evershine is local Partner of ADP Streamline® in Taiwan.
(版本:2025/10)