## Case #2: Separated Schema 導致 Database Objects 上限風險

### Problem Statement（問題陳述）
業務場景：每租戶一個 Schema，為因應自定義需求，為每租戶複製表/檢視/觸發器/函數等物件（約 5,000 個/租戶）。已部署在單一資料庫中集中管理。
技術挑戰：SQL Server 每個資料庫的 database objects 總數上限約 2,147,483,647；按 5,000 物件/租戶估算上限約 400,000 租戶，且對 DDL/維運/備份造成巨大負載。
影響範圍：當租戶數接近上限，新增租戶成本高、風險大，且部署與版本管理複雜。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 每租戶複製大量 DB 物件，逼近 object 上限。
2. 物件爆炸造成部署腳本龐大與易錯。
3. 跨租戶共享資料難以整合。

深層原因：
- 架構層面：以 Schema 做隔離的過渡設計。
- 技術層面：忽視統一 schema 的可維護性與索引共享。
- 流程層面：版本演進需 N 倍 DDL，風險與成本線性放大。

### Solution Design（解決方案設計）
解決策略：收斂至 Shared Schema，減少 DB 物件複本，改用 TenantId 隔離與參數化自定義；僅保留小量 per-tenant 結構（如稀有特殊需求）。

實施步驟：
1. 物件盤點與分級
- 實作細節：分為共用、少量特例、可淘汰；產出清單。
- 所需資源：DBA、開發、CMDB。
- 預估時間：1 週。

2. 共用化重構
- 實作細節：集中共用表與檢視；用 TenantId 區分。
- 所需資源：T-SQL、CI/CD。
- 預估時間：2 週。

3. 自定義能力重設
- 實作細節：以設定檔/Feature Flag 取代 DDL。
- 所需資源：設定服務、管理後台。
- 預估時間：1-2 週。

關鍵程式碼/設定：
```sql
-- 盤點各 schema 下物件數量，評估爆炸程度
SELECT s.name AS SchemaName, COUNT(o.object_id) AS ObjectCount
FROM sys.objects o
JOIN sys.schemas s ON o.schema_id = s.schema_id
GROUP BY s.name ORDER BY ObjectCount DESC;

-- 將多 schema 表收斂到共用表 + TenantId
CREATE TABLE dbo.Customer (
  TenantId UNIQUEIDENTIFIER NOT NULL,
  CustomerId BIGINT NOT NULL,
  Name NVARCHAR(200) NOT NULL,
  CONSTRAINT PK_Customer PRIMARY KEY (TenantId, CustomerId)
);

## Case #3: 多資料庫連線與資源浪費（Separated DB）導致效能不穩

### Problem Statement（問題陳述）
業務場景：上千個小型 DB 同時運行，應用層需要頻繁切換連線字串以服務不同租戶；尖峰時段連線數逼近 SQL Server 上限 32767。
技術挑戰：連線/緩衝/計劃快取碎片化造成 CPU 上升，且管理成本高（備份、監控、補丁）。
影響範圍：延遲升高、資源浪費、成本攀升。
複雜度評級：中

### Root Cause Analysis
直接原因：
1. 多 DB 帶來連線與計劃快取碎片化。
2. 小 DB 也要承擔 DB 級元件開銷。
3. 連線數逼近 32767 上限，導致錯誤與節流。

深層原因：
- 架構層面：過度分割成多 DB。
- 技術層面：連線池利用率低、跨 DB 事務與查詢困難。
- 流程層面：租戶入租須建 DB，放大成本。

### Solution Design
解決策略：合併至 Shared Schema 或少量 Shard DB，借助連線池；集中計劃快取與索引行為。

實施步驟：
1. 減 DB 改 Shard/Shared
- 實作細節：將數千 DB 收斂為少量 Shard 或 1 個 Shared。
- 資源：DBA、遷移工具。
- 時間：3-6 週。

2. 連線池優化
- 實作細節：統一連線字串；Min/Max Pool 設定。
- 資源：應用程式設定。
- 時間：0.5 週.

3. 計劃快取/索引調整
- 實作細節：常用查詢預熱，固定複合索引。
- 資源：DBA。
- 時間：1 週。

關鍵程式碼/設定：
```csharp
// 統一連線 + 連線池設定
var cs = "Server=...;Database=SharedDB;User Id=...;Password=...;Min Pool Size=50;Max Pool Size=500;";
using var conn = new SqlConnection(cs);

// 共用查詢：以參數強制租戶過濾
var cmd = new SqlCommand("SELECT * FROM Orders WHERE TenantId=@tid AND OrderId=@oid", conn);

## Case #4: 跨資料庫的共用資料查詢困難

### Problem Statement
業務場景：雖採多租戶，每個租戶仍需共用部分基準資料（如產品目錄、國家/幣別）；現行 Separated DB 導致查詢需跨上千 DB。
技術挑戰：跨 DB 查詢維護困難、延遲高、風險大。
影響範圍：報表、搜尋、同步任務複雜化。
複雜度評級：中

### Root Cause Analysis
直接原因：
1. 共用資料被複製在各租戶 DB。
2. 跨 DB join/union 成本與維護度極高。
3. 更新共用資料需 N 份，易不一致。

深層原因：
- 架構層面：資料共用未分離成全球性資料域。
- 技術層面：無中央資料庫/服務。
- 流程層面：資料治理與同步機制薄弱。

### Solution Design
解決策略：建立 Global Shared DB（或服務），所有共用資料集中管理；在租戶 DB 內以 Synonym/View 指向共用資料，或全面轉 Shared Schema。

實施步驟：
1. 建立 Shared DB 與資料域
- 細節：單一真實來源（SSOT）。
- 資源：DBA、資料治理。
- 時間：1 週。

2. 應用程式調整
- 細節：使用 Synonym 或直接連 Shared DB。
- 資源：應用程式變更。
- 時間：1 週。

關鍵程式碼/設定：
```sql
-- 在租戶 DB 建立同義詞，轉向共用資料庫
CREATE SYNONYM dbo.Country FOR SharedDb.dbo.Country;
CREATE SYNONYM dbo.Currency FOR SharedDb.dbo.Currency;

-- 應用端不用改 SQL，只需改連入物件
SELECT * FROM dbo.Country WHERE IsActive = 1;

## Case #5: Shared Schema 大表（億級）慢查詢與索引維護成本高

### Problem Statement
業務場景：Shared Schema 把所有租戶資料集中，單表很快超過億級筆數。常見操作（插入/更新）導致索引維護昂貴；部分 Join/查詢顯著變慢。
技術挑戰：單表超大、索引更新成本高；查詢未命中複合索引而 scan。
影響範圍：高延遲、阻塞、交易時間長。
複雜度評級：高

### Root Cause Analysis
直接原因：
1. 索引鍵未以 TenantId 打頭，導致全表/大範圍掃描。
2. 無分割表（partition），熱/冷資料混在一起。
3. 廣播式 Join、未覆蓋索引造成 IO 爆炸。

深層原因：
- 架構層面：未針對多租戶設計索引與分割。
- 技術層面：忽略寫入密集時的索引維護成本。
- 流程層面：缺乏索引基準測試與可觀測性。

### Solution Design
解決策略：以 TenantId 為前導鍵建立複合聚簇索引；建立必要的覆蓋索引；按時間或租戶進行表分割；避免廣播 Join，改以查詢重寫。

實施步驟：
1. 索引策略重設
- 細節：聚簇索引 (TenantId, PK)，覆蓋索引（含 INCLUDE）。
- 資源：DBA、工作負載分析。
- 時間：1-2 週。

2. 分割表
- 細節：依時間（CreatedAt）或 hash(TenantId) 分區。
- 資源：分割函數/配置。
- 時間：1-2 週。

3. 查詢重寫與提示
- 細節：強制索引、避免 SELECT *、限制 Join。
- 資源：程式改動。
- 時間：1 週。

關鍵程式碼/設定：
```sql
-- 複合聚簇索引：TenantId + OrderId
CREATE UNIQUE CLUSTERED INDEX CX_Orders_Tenant_OrderId
ON dbo.Orders (TenantId, OrderId);

-- 覆蓋索引：常見查詢欄位
CREATE INDEX IX_Orders_Tenant_Created ON dbo.Orders (TenantId, CreatedAt)
INCLUDE (Status, Amount);

-- 按時間分割（示例）
CREATE PARTITION FUNCTION PF_DateRange (DATETIME2)
AS RANGE RIGHT FOR VALUES ('2024-01-01', '2024-07-01', '2025-01-01');

CREATE PARTITION SCHEME PS_Orders AS PARTITION PF_DateRange TO ([FG2023],[FG2024H1],[FG2024H2],[FG2025]);

## Case #6: RDBMS 難以水平擴展（Scale Out）需應用層分片（Sharding）

### Problem Statement
業務場景：Shared Schema 儘管優化後仍遇到單機瓶頸；需跨多台 SQL Server 機器分散負載。
技術挑戰：資料庫不易 Scale Out；需依租戶分片，應用層需要路由。
影響範圍：查詢路由、交易一致性、維運複雜。
複雜度評級：高

### Root Cause Analysis
直接原因：
1. 單機 DB 垂直擴充已近極限。
2. 多租戶集中導致熱租戶壓力。
3. 資料庫層缺乏透明的分片機制。

深層原因：
- 架構層面：未早期規劃分片。
- 技術層面：缺少分片映射與路由中介層。
- 流程層面：版本發布需跨多分片協調。

### Solution Design
解決策略：以 TenantId 做一致性映射至多個 DB（Shard）；建立分片映射表與路由 SDK；支援平滑再平衡與觀測。

實施步驟：
1. 分片策略設計
- 細節：哈希/範圍分片；Shard Map（表/服務）。
- 資源：設計/POC。
- 時間：1 週。

2. 應用層路由
- 細節：依 TenantId 查 Shard Map 取得連線。
- 資源：中介 SDK。
- 時間：2 週。

3. 再平衡與遷移
- 細節：冷熱分析，搬移租戶資料。
- 資源：ETL/遷移工具。
- 時間：2-4 週。

關鍵程式碼/設定：
```csharp
// 簡化版分片映射
record Shard(string ShardId, string ConnectionString);
static Shard ResolveShard(Guid tenantId)
{
    var shardIndex = Math.Abs(tenantId.GetHashCode()) % shardCount;
    return shardMap[shardIndex];
}

// 取得連線並執行查詢
using var conn = new SqlConnection(ResolveShard(tenantId).ConnectionString);

## Case #7: 避免執行期建立 DB/TABLE（動態 DDL）造成風險

### Problem Statement
業務場景：入租時動態建立 DB/TABLE，導致鎖定、資源競爭、部署風險與延遲。
技術挑戰：DDL 與 DML 混用時的鎖爭、回滾困難。
影響範圍：SLA、穩定性、回復時間。
複雜度評級：中

### Root Cause Analysis
直接原因：
1. 多租戶入租高峰同時執行 DDL。
2. DDL 導致元資料鎖與計劃快取失效。
3. 邏輯與資料遷移耦合。

深層原因：
- 架構層面：以結構變更作為租戶變更手段。
- 技術層面：缺少 migration pipeline。
- 流程層面：無灰度/回滾。

### Solution Design
解決策略：預先佈署結構、以資料驅動入租；導入 migration pipeline（版本化、可回滾、灰度）。

實施步驟：
1. 版本化遷移
- 細節：每版 schema 管控，idempotent。
- 資源：Flyway/DbUp/自建工具。
- 時間：1 週。

2. 入租資料化
- 細節：只建立租戶記錄與預設設定值。
- 資源：應用程式。
- 時間：0.5 週。

關鍵程式碼/設定：
```yaml
# CI/CD 範例（GitHub Actions）
- name: Run DB migrations
  run: flyway -url=jdbc:sqlserver://... -user=... -password=... migrate

## Case #8: Azure Table Storage 的 PartitionKey/RowKey 設計（避免熱分割區）

### Problem Statement
業務場景：改用 Azure Table Storage 儲存多租戶資料，但因 PartitionKey 設計不佳導致熱分割區、吞吐受限。
技術挑戰：必須同時滿足資料局部性（查詢效率）與分散（可擴展）。
影響範圍：請求節流（throttling）、延遲增大、成本上升。
複雜度評級：中

### Root Cause Analysis
直接原因：
1. 將所有租戶放同一 PartitionKey。
2. RowKey 不可區分排序或缺乏唯一性。
3. 查詢模式與鍵設計不吻合。

深層原因：
- 架構層面：未以存取路徑反推鍵設計。
- 技術層面：忽視 Partition 的自動負載均衡特性。
- 流程層面：缺少鍵設計準則與設計審查。

### Solution Design
解決策略：以 TenantId 作高階分區，再加時間/類型做細分；RowKey 採可排序且唯一的編碼（如反向 Ticks + 業務鍵），兼顧查詢局部與擴散。

實施步驟：
1. 設計規則
- 細節：PartitionKey = TenantId#Type#yyyyMM；RowKey = ReverseTicks#EntityId。
- 資源：設計評審。
- 時間：0.5 週。

2. SDK 實作
- 細節：基底實體/工廠方法統一鍵生成。
- 資源：.NET Azure.Data.Tables。
- 時間：1 週。

關鍵程式碼/設定：
```csharp
public sealed class MtEntity : ITableEntity {
  public string PartitionKey { get; set; }
  public string RowKey { get; set; }
  public DateTimeOffset? Timestamp { get; set; }
  public ETag ETag { get; set; }
  public Guid TenantId { get; set; }
  public static MtEntity Create(Guid tenantId, string type, DateTimeOffset ts, string id) {
    var pk = $"{tenantId:N}#{type}#{ts:yyyyMM}";
    var rk = $"{long.MaxValue - ts.UtcTicks:D19}#{id}";
    return new MtEntity { PartitionKey = pk, RowKey = rk, TenantId = tenantId };
  }
}

## Case #9: Table Storage 查詢效能低下（未命中 PartitionKey）

### Problem Statement
業務場景：開發人員以非鍵欄位查詢 Table Storage（如 Email），導致全表掃描、延遲高。
技術挑戰：Table Storage 僅對 PartitionKey/RowKey 有索引。
影響範圍：查詢延遲、成本、節流風險。
複雜度評級：入門級

### Root Cause Analysis
直接原因：
1. 以非鍵欄位過濾查詢。
2. Partition 設計與存取路徑不符。
3. 缺少輔助索引表。

深層原因：
- 架構層面：忽略鍵驅動效能。
- 技術層面：誤用 RDBMS 思維。
- 流程層面：缺少查詢規約。

### Solution Design
解決策略：所有查詢必須包含 PartitionKey；若需用其他屬性查詢，建立 Secondary Index Table（見 Case #11）。

實施步驟：
1. 規約制定
- 細節：DAL/Repo 層禁止未帶 PartitionKey 的查詢。
- 資源：靜態分析/審查。
- 時間：0.5 週。

2. 查詢重寫
- 細節：加入 PartitionKey 與 RowKey 範圍。
- 資源：程式修改。
- 時間：1 週。

關鍵程式碼/設定：
```csharp
// 正確：以 PartitionKey + RowKey 範圍查詢
var filter = TableClient.CreateQueryFilter<MtEntity>(e =>
  e.PartitionKey == pk && e.RowKey.CompareTo(start) >= 0 && e.RowKey.CompareTo(end) <= 0);
var results = tableClient.Query<MtEntity>(filter);

## Case #10: Table Storage 無法任意排序，如何支援時間倒序

### Problem Statement
業務場景：需要以時間倒序顯示最新記錄，但 Table Storage 僅按 PartitionKey + RowKey 升序。
技術挑戰：無 server-side sort；僅能利用 RowKey 排序特性。
影響範圍：列表頁、時間線、審計。
複雜度評級：入門級

### Root Cause Analysis
直接原因：
1. 嘗試以一般欄位排序，不被支援。
2. RowKey 未編碼排序語義。
3. 客端排序造成大資料拉取。

深層原因：
- 架構層面：排序需求未映射到鍵設計。
- 技術層面：忽略 RowKey 可攜排序。
- 流程層面：需求/設計對齊不足。

### Solution Design
解決策略：RowKey 使用 ReverseTicks（long.MaxValue - ticks）實現倒序；或在 RowKey 前綴加入可分群欄位。

實施步驟：
1. RowKey 設計
- 細節：RowKey = ReverseTicks#Id。
- 資源：鍵生成庫。
- 時間：0.5 週。

2. 分頁/過濾
- 細節：以 RowKey 範圍 + Continuation Token。
- 資源：SDK 實作。
- 時間：0.5 週。

關鍵程式碼/設定：
```csharp
static string NewRowKey(DateTimeOffset ts, string id) =>
  $"{long.MaxValue - ts.UtcTicks:D19}#{id}";

// 查詢：自然得到最新在前（升序下的反向 ticks）
var filter = TableClient.CreateQueryFilter<MtEntity>(e => e.PartitionKey == pk);
var page = tableClient.Query<MtEntity>(filter, maxPerPage: 50).AsPages().First();

## Case #11: Table Storage 缺乏二級索引，如何實作次索引表

### Problem Statement
業務場景：需以 Email 搜尋使用者，但 Email 非 PartitionKey/RowKey 屬性，直接查詢極慢。
技術挑戰：Table Storage 無二級索引。
影響範圍：搜尋與關聯查詢體驗差。
複雜度評級：中

### Root Cause Analysis
直接原因：
1. 非鍵欄位查詢需全掃描。
2. 未建立輔助映射表。
3. 寫入時未雙寫索引表。

深層原因：
- 架構層面：未用表設計換取查詢效率。
- 技術層面：缺少一致性與重試。
- 流程層面：缺少寫入規約。

### Solution Design
解決策略：建立 EmailIndex 表：PartitionKey=TenantId，RowKey=Lower(Email)，Value=UserPK；寫入/更新時雙寫；查詢先查索引再取主表。

實施步驟：
1. 索引表設計
- 細節：避免碰撞；低卡控鍵。
- 資源：資料模型。
- 時間：0.5 週。

2. 寫入流程改造
- 細節：交易/重試（同分區批次）。
- 資源：SDK。
- 時間：1 週。

關鍵程式碼/設定：
```csharp
public class EmailIndex : ITableEntity {
  public string PartitionKey { get; set; } // tenant
  public string RowKey { get; set; } // lower(email)
  public string UserPk { get; set; } // 主表的 PK （例如 PartitionKey#RowKey）
  public DateTimeOffset? Timestamp { get; set; }
  public ETag ETag { get; set; }
}

// 寫入雙寫（同分區可批次）
var batch = new List<TableTransactionAction> {
  new(TableTransactionActionType.Add, userEntity),
  new(TableTransactionActionType.Add, emailIndexEntity)
};
await tableClient.SubmitTransactionAsync(batch);

## Case #12: Table Storage 無 JOIN，如何以去正規化換取讀取效能

### Problem Statement
業務場景：列表頁需要顯示訂單與客戶名稱，原模型需 JOIN 客戶表；Table Storage 無 JOIN。
技術挑戰：避免多次讀取與拼接成本。
影響範圍：列表/報表、API 延遲。
複雜度評級：入門級

### Root Cause Analysis
直接原因：
1. 直接模仿 RDBMS 正規化模型。
2. 每筆顯示需讀兩張表。
3. 頻繁跨表導致請求數暴增。

深層原因：
- 架構層面：未針對查詢設計資料模型。
- 技術層面：忽略去正規化的重要性。
- 流程層面：缺少寫入更新流程。

### Solution Design
解決策略：在訂單實體中冗餘 CustomerName、CustomerEmail；寫入/更新時同步；非強一致場景可接受最終一致。

實施步驟：
1. 模型調整
- 細節：在 Order 寫入顧客快照欄位。
- 資源：資料模型。
- 時間：0.5 週。

2. 更新流程
- 細節：顧客更新時觸發批次更新（可延遲）。
- 資源：消息/工作排程。
- 時間：1 週。

關鍵程式碼/設定：
```csharp
public class OrderEntity : ITableEntity {
  public string PartitionKey { get; set; } // tenant#yyyyMM
  public string RowKey { get; set; } // reverseTicks#orderId
  public string CustomerId { get; set; }
  public string CustomerName { get; set; } // 去正規化
  public string CustomerEmail { get; set; } // 去正規化
  // ...
}

## Case #13: Table Storage 無 COUNT/聚合，如何做高效計數

### Problem Statement
業務場景：儀表板需要顯示訂單數、總額；Table Storage 無內建 COUNT。
技術挑戰：全表掃描昂貴；需維護計數器的一致性。
影響範圍：儀表板延遲、成本。
複雜度評級：中

### Root Cause Analysis
直接原因：
1. 嘗試以掃描計數，成本高。
2. 未維護聚合實體。
3. 缺少並發控制。

深層原因：
- 架構層面：未設計衍生資料（Derived Data）。
- 技術層面：忽略 ETag/並發。
- 流程層面：缺少重試/補償。

### Solution Design
解決策略：為每租戶維護 CounterEntity（當日/當月）；使用 ETag 進行樂觀併發；寫入時增量更新；定期重建校正。

實施步驟：
1. Counter 模型
- 細節：PartitionKey=TenantId#yyyyMM，RowKey=MetricName。
- 資源：模型/SDK。
- 時間：0.5 週。

2. 增量更新
- 細節：提交交易（同分區）或重試更新。
- 資源：SDK。
- 時間：1 週。

關鍵程式碼/設定：
```csharp
// 樂觀鎖更新計數
var counter = await table.GetEntityAsync<Counter>(pk, rk);
counter.Count += 1;
await table.UpdateEntityAsync(counter, counter.ETag, TableUpdateMode.Replace);

## Case #14: Table Storage 分頁（Continuation Token）設計

### Problem Statement
業務場景：需要穩定分頁 API；Table Storage 不支援 offset，需使用 Continuation Token。
技術挑戰：確保排序穩定與令牌安全傳遞。
影響範圍：列表 API、前端體驗。
複雜度評級：入門級

### Root Cause Analysis
直接原因：
1. 嘗試 offset/limit，導致掃描或結果不穩。
2. 未管理 Continuation Token。
3. 排序鍵不穩定。

深層原因：
- 架構層面：未用鍵排序支援分頁。
- 技術層面：令牌處理與安全未落實。
- 流程層面：API 規約不足。

### Solution Design
解決策略：固定 PartitionKey + RowKey 排序；使用 SDK 的 AsPages() 取得 Continuation Token；令牌以 Base64/加密封裝。

實施步驟：
1. API 設計
- 細節：pageSize、token；排序固定。
- 資源：API 契約。
- 時間：0.5 週。

2. SDK 實作
- 細節：AsPages(maxPerPage)；傳回 token。
- 資源：程式修改。
- 時間：0.5 週。

關鍵程式碼/設定：
```csharp
var pageable = tableClient.Query<MtEntity>(filter, maxPerPage: pageSize);
var page = pageable.AsPages(continuationToken, pageSize).FirstOrDefault();
return new PagedResult { Items = page.Values, NextToken = page.ContinuationToken };

## Case #15: Table Storage 報表困難，建 ETL 到 SQL 生成分析報表

### Problem Statement
業務場景：需要複雜報表與統計（JOIN、群組、聚合）；Table Storage 非關聯不適合直接產報。
技術挑戰：在不中斷線上負載下，將資料搬運到 RDBMS 供分析。
影響範圍：BI 報表、商務分析。
複雜度評級：中

### Root Cause Analysis
直接原因：
1. Table Storage 無聚合/Join/排序能力。
2. 全掃描成本過高。
3. 缺少穩定 ETL 管線。

深層原因：
- 架構層面：未規劃分析層（OLAP）。
- 技術層面：缺少批處理/增量抽取。
- 流程層面：資料時效性與成本未平衡。

### Solution Design
解決策略：建立每日/每小時 ETL，將 Table Storage 增量同步至 Azure SQL/SQL Server，於 RDBMS 上建模報表與指標。

實施步驟：
1. 增量抽取
- 細節：依 Timestamp/RowKey 範圍抽取。
- 資源：ADF/函式/作業。
- 時間：1-2 週。

2. 維度建模
- 細節：星型/雪花模型、索引/分割。
- 資源：DBA/BI。
- 時間：2 週。

關鍵程式碼/設定：
```csharp
// 簡易搬運：讀取某期間 Table Entities -> 寫入 SQL
await foreach (var page in table.Query<MtEntity>(filter, maxPerPage: 1000).AsPages()) {
  BulkInsert(sqlConnection, Transform(page.Values));
}

## Case #16: 多儲存混合（Polyglot Persistence）：RDBMS + Table Storage

### Problem Statement
業務場景：同時需要關聯查詢（訂單結算/合規）與海量事件/日誌的高可擴展寫入。
技術挑戰：單一儲存難以兼顧 ACID 與大規模擴展。
影響範圍：一致性、性能、成本。
複雜度評級：高

### Root Cause Analysis
直接原因：
1. 將不同負載硬塞同一儲存。
2. RDBMS 難以承擔超高寫入與廉價存儲。
3. Table Storage 不適合複雜交易。

深層原因：
- 架構層面：未按工作負載分層。
- 技術層面：缺少跨儲存一致性策略。
- 流程層面：監控與補償未完善。

### Solution Design
解決策略：交易性資料（核心帳務）留在 SQL；高寫入事件（審計/操作）進 Table Storage；以消息驅動同步必要摘要到 SQL 作分析；最終一致。

實施步驟：
1. 邊界劃分
- 細節：按事務與查詢類型界定。
- 資源：架構設計。
- 時間：1 週。

2. 同步與補償
- 細節：事件驅動、重試、對賬。
- 資源：消息中介/函式。
- 時間：2 週。

關鍵程式碼/設定：
```csharp
// 寫入交易到 SQL
await sql.SaveOrderAsync(order);
// 同步事件到 Table Storage
await table.AddEntityAsync(OrderEvent.Create(order));

// 從事件回填彙總到 SQL
ProcessEventsAndUpsertAggregates();