DynamoDB 是關聯式資料庫嗎？

不是。DynamoDB 不是關聯式資料庫 — 它是一個 NoSQL 鍵值與文件儲存。這裡沒有具固定結構的資料表、沒有外鍵，也沒有 join。你是圍繞應用程式的存取模式來建模並做去正規化，而不是像在關聯式（SQL）資料庫裡那樣跨相關資料表做正規化。如果你懷念關聯式的工作流程，DynoTable 在用戶端把其中一部分帶了回來：一個能執行真正 JOIN 與 GROUP BY 的 SQL Workbench，以及能視覺化 join 資料表的 Smart Table。

為什麼它不是關聯式的

關聯式資料庫會強制執行結構、把資料正規化到許多資料表中，並在讀取時把它們 join 起來。DynamoDB 做的正好相反：它儲存無結構的項目，並期待你透過複製或內嵌相關資料來預先做好 join。

什麼取代了關聯式的功能

Join → 去正規化與單一表格設計。
正規化的資料表 → 歸在同一個分割區索引鍵之下的項目集合。
臨機 SQL → 以鍵為基礎的 Query 與 Scan，或者 PartiQL（一個與 SQL 相容的子集，一樣沒有 join）。

順帶一提，PartiQL 並沒有補上這個落差。它的剖析器會拒絕跨兩張資料表的 SELECT，也會拒絕 GROUP BY，兩者都發生在讀取任何東西之前；確切的拒絕內容引用在 DynamoDB 支援 join 嗎與 DynamoDB 支援 SQL 嗎。

去正規化實際上讓你付出什麼

這個取捨通常被描述成「複製資料而不是 join」，聽起來像是一個儲存上的決定。它其實是一個關於寫入與原子性的決定，而那正是關聯式引擎替你藏起來的部分。

假設有一位客戶有 5,000 筆訂單，而這位客戶改了顯示名稱。在關聯式結構中那是對一列的一次 UPDATE，而每一次 join 都會立刻取到新值。去正規化到 DynamoDB 之後，那個名稱住在全部 5,000 個訂單項目上，所以這次改名就是 5,000 次項目寫入：5,000 個寫入單位，以每個項目 1 KB 計，在 us-east-1 隨需模式下約 $0.003。

錢不是問題。問題在於它不可能是一次操作。TransactWriteItems 的上限是 100 個動作，所以 5,000 個項目至少是 50 筆各自獨立的交易，而它們之間沒有隔離性。在那個扇出跑完之前，你自己的資料彼此不一致，而任何落在中途的讀取都會看到新舊名稱混雜。

關聯式資料庫替你買到的正是這個：對唯一權威副本的一次原子變更。放棄它，才是真正的入場費，也是為什麼「哪些屬性要被複製」值得比「哪些屬性要建索引」得到更多設計上的注意。

深入了解

閱讀如何在 DynamoDB 中建模資料與單一表格設計。下載 DynoTable 就能視覺化地探索你的資料模型 — 並用 SQL Workbench 對它執行關聯式風格的 JOIN/GROUP BY 查詢。

參考資料

最後查證於 2026-07-13，對照上方連結的官方 AWS 文件；100 個動作的交易上限已於 2026-07-28 從 API 參考重新取回。