資料建模

這是 DynamoDB 與 SQL 分歧最劇烈之處。你不會把資料正規化成每個實體一張表 — 而是從你的存取模式出發，設計能服務它們的鍵，往往把每個實體都塞進單一表格。做對了，你就能用一次 Query 取回一個父項與它的子項，不需要 join。

做錯了，你會得到一張查不動的表格，以及一場跑不起來的遷移。所以取捨很重要，而本節會誠實地談那些單一表格設計屬於錯誤選擇的情境。

從單一表格設計開始 — 它之後的一切都假設了那套心智模型。

在動手建置前，先用免費的單一資料表設計工具畫出 schema 草圖 — 它能把一份存取模式清單變成 PK/SK/GSI 規劃。接著 試用 DynoTable 來對著一張線上表格建模並瀏覽這些佈局 — 而對於你的鍵 服務不到的臨機問題，它的 SQL Workbench 能在用戶端執行 JOIN、GROUP BY 與彙總。