AI時代的關聯式資料庫現況

C.M.Lin & ChatGPT (2026/3)

在 AI 浪潮下，資料庫似乎面臨新的定義。例如現在經常聽到所謂AI大數據，這個大數據到底是甚麼？在某種情境之下，AI大數據似乎經常代表的是"海量的文件"，包括所有的網頁、儲存的文件檔，被AI的程式消化吸收之後應用。這裡的大數據是網頁、文件、甚至影音檔案。這些也有被統稱為「向量資料庫」（Vector Database）。

這種資料庫的概念，和關聯式資料庫（RDBMS）完全不同。以往我們說的大數據分析，經常是在關聯式資料庫裡面找意義，例如最有名的教科書案例：啤酒與尿布，就是從RDBMS所建立的超級市場銷售資料庫當中，許多筆的交易資料裡面找出的商業智慧。

在AI時代，會用到向量資料庫。那麼，RDBMS還有需要嗎？目前的狀況應該是，RDBMS功能更多了，也就是在既有功能下更升級，轉型，而且會和向量資料庫共生。

RDBMS仍是系統開發重點

雖然 AI 處理的是非結構化數據（如文章、圖片、音訊），但任何一個「系統」不只有 AI。一個完整的 AI 應用程式（如 AI 客服或電商推薦系統）仍然需要處理：

• 帳號權限： 誰能登入？

• 交易紀錄： 訂單編號、金額、時間。

• 業務邏輯： 商品庫存、使用者標籤、聯絡資訊。

這些高度結構化、需要 ACID（原子性、一致性、隔離性、持久性）保證的資料，關聯式資料庫依然是目前世界上最可靠的選擇。

根據 2026 年最新的開發趨勢與 DB-Engines 排名：

• 新開發專案： 大多數開發者在啟動新專案時，首選依然是關聯式資料庫。

• 混合架構（Hybrid Architecture）： 現在流行的做法不是「二選一」，而是「1+1」。系統的傳統資料存放在 PostgreSQL 或 MySQL，而 AI 需要的「向量索引（Embeddings）」則存放在向量資料庫或原資料庫的擴展插件中。

目前AI 與關聯式資料庫的關係，主要技術路徑分為兩條：

• RAG 模式（檢索增強生成）： 這是目前企業最主流的應用。AI 會先去資料庫撈出「相關知識」，再把知識餵給大模型（LLM）生成回答。

• AI 直接查 SQL： 包括 AI Agent（AI 代理人）趨勢，現在許多系統能讓 AI 自動將人類的口語轉成 SQL 指令（Text-to-SQL），直接去關聯式資料庫抓取數據。這讓不懂 SQL 的一般員工也能直接查詢公司資料。

目前(2026)市場上主流的軟體工具如下：

PostgreSQL： 透過 pgvector 插件，它能同時處理傳統 SQL 與 AI 向量檢索。

MySQL：大量網站、CMS、電商系統的基礎，現在也正積極整合向量搜尋功能。

Oracle / SQL Server：針對大型企業（金融、製造業）的複雜運算，提供強大的安全性與 AI 擴充。

SQLite：手機 App、邊緣運算設備的主要選擇，體積小卻極其穩定。

AI 專用：Pinecone / Milvus，純向量資料庫。 專門為了處理超大規模的 AI 資料檢索而生，常與上述 SQL 資料庫並行使用。

-------------------------

辦公室環境中的試算表軟體前途

很多員工習慣用 Excel 或 Google Sheets，是因為它們很直覺，也是大多數職員工在學校時期學過的軟體，也可說是大多數人擁有的技能。但是試算表軟體的致命缺點是，當資料量變大、需要跨年度（時間維度）或跨類型（關聯維度）時，這種「扁平化」的整理方式會讓辦公室陷入數據災難。

「表格式軟體」在處理複雜資料時，經常遇到不同檔案，不同表格之間資料不一致、重複，或者後來的修改修訂之後，在不同表格之間出現差異的問題，更不用說如果想要跨表格做資料分析，例如，請幫忙分析這十年的學生成績變化。當成績分散在每年不同的檔案當中時，這類型的分析需求會耗掉許多時間，甚至更嚴重會出現操作過程的錯誤導致分析結果錯誤的問題。

在關聯式資料庫的概念中，這被稱為**「資料冗餘」與「維護異常」**。

• 跨年度斷層： 員工習慣一年開一個分頁（Sheet），想看過去五年的趨勢時，得手動複製貼上或寫極其複雜的 VLOOKUP，出錯率極高。

• 一對多關係的崩潰： 例如一個客戶（類型 A）有多筆訂單（類型 B）。在 Excel 裡，員工若不是重複輸入客戶資訊，就是把所有東西塞在同一個儲存格，導致最後無法進行統計分析。

• 缺乏唯一識別碼（Primary Key）： 只要有人把「台南分公司」誤打成「臺南分公司」，統計就會出錯。

其實，RDBMS就是在解決這些問題，但是叫行政人員去學 RDBMS太難了。但現在 AI + No-Code/Low-Code（低代碼） 工具正在改變遊戲規則：

A. AI 輔助的資料庫建模 (Natural Language to Schema)

現在的工具（如 Airtable 或 Notion DB）已經可以讓員工用「講話」的方式建立資料庫。

員工口語： 「幫我建立一個可以追蹤客戶購買紀錄的系統，要能分年份統計，且客戶資訊只需要輸入一次。」

AI 回應： 自動生成「客戶表」與「訂單表」，並設定好兩者之間的「關聯」。

B. 語意化查詢 (Text-to-SQL)

這是最關鍵的進展。員工不需要懂 JOIN 或 GROUP BY。

員工詢問： 「幫我比較過去三年，北部地區在第一季的銷售成長率。」

AI 運作： 背後自動寫出跨年度、跨表格的查詢指令，直接從資料庫抓出結果並畫成圖表。

對於缺乏資料庫概念的員工，可能有必要進行教育訓練，須了解「關聯屬性」：須瞭解到「資料只需要在一個地方修改，其他地方會同步」的好處。引入 AI 助手。讓員工發現透過「問問題」就能得到跨年度統計，進而引發他們優化資料結構的動機。

------------------------------

AI黑箱導致業務邏輯更神祕

在辦公室環境，我們希望員工能善加利用軟體。但高度使用"高彈性軟體"的情況有另一個問題就是交接或代理困難。Excel就是一種高彈性軟體，讓員工可以自己決定把資料放在哪些欄位？哪些表格？甚至裡面決定使用某些函數或公式，當檔案需要交接，或者需要有代理人協助處理事務時，這些都表格裡面的業務邏輯，都是一道銜接的高牆。

當我們過度依賴 AI 來建立「關聯」或「查詢」時，這道高牆會變得更高，因為AI幫我們建立了邏輯，或者根據我們的邏輯建立了工具，但這過程可能會像是個黑箱。甚至連原先的員工都不見得完全理解所有的過程，更遑論萬一需要交接。辦公室會因此面臨一個核心風險：「黑盒化作業」與「流程斷層」。

如果員工不理解資料庫的邏輯（例如：為什麼 A 表跟 B 表能串在一起），只是下指令讓 AI 產出結果，那麼一旦 AI 出錯，或者系統需要調整時，沒有人能看出問題在哪裡。

以下是初步的建議：

建立「透明化」與「手動化」的鷹架。要避免上述問題，我們不能只讓 AI 「做」，而是要讓 AI 「解釋並建立文件」。可以考慮以下三種策略來強化流程：

A. 「雙語化」作業說明書

要求 AI 在產生任何資料庫結構或查詢時，必須同時產出一份**「人類可讀的邏輯文件」**。

要求 AI： 「請建立一個跨年度預算表，並用簡單的白話文解釋：你是根據哪個欄位把去年的資料連過來的？如果資料重複了你會怎麼處理？」

目的： 讓員工在操作的同時，也被迫理解資料庫的「外鍵（Foreign Key）」與「去重（De-duplication）」概念。

B. 導入「數據治理（Data Governance）」的小規模規範

即使不學 SQL，辦公室也應該建立幾條鐵律（Metadata Rules）：

• 命名規範： 所有表格欄位名稱必須統一（例如：不能在 A 表叫「姓名」，B 表叫「聯絡人」）。

• 唯一識別碼（ID）的強制性： 任何資料進系統前，必須有一個「身分證」或「編號」，不能只靠姓名。

• 定期的人工審核點： 在 AI 產出報表後，必須有 5% 的資料抽樣，由人工手動核對。

C. 利用「白盒」工具（Low-Code）

與其讓 AI 在黑盒中寫程式，不如讓 AI 在 Airtable 或 Ragic 這種可視化工具中操作。

• 可見性： 這些工具會把資料關聯畫成線條或選單。

• 視覺化檢核： 員工雖然不會寫 code，但看得到「這條線連到了那一張表」，這就是一種直覺的邏輯訓練。

也許不需要每個行政人員都變成資料庫工程師，但需要他們具備基本的「數據素養」：

1. 知道資料在哪裡？（資料來源）

2. 知道資料怎麼連？（關聯邏輯）

3. 知道結果對不對？（預期檢驗）