Access 系統移行到 Power Platform 時的三種架構方案比較：Dataverse、Azure SQL、Azure Functions 的差異

| PowerPlatform | 6 Reads

Copyright Notice: This article is an original work licensed under the CC 4.0 BY-NC-ND license. If you wish to repost this article, please include the original source link and this copyright notice.
Source link: https://v2know.com/article/1307

最近在研究一個既有的 Access 系統移行問題。這類 .accdb 系統通常不只是「資料庫檔案」，而是把資料表、查詢、畫面、VBA、報表、列印預覽等功能全部包在一起的小型業務系統。以「処理状況等管理システム」這類 Access 系統為例，它本身就是準備往 Power Platform 方向移行的既有 Access 系統 。

因此，在考慮移行時，不能只問「資料放哪裡」，而是要同時考慮：

畫面由誰負責？
資料放在哪裡？
原本的 Access Query / SQL 怎麼處理？
VBA 業務邏輯搬到哪裡？
帳票 / PDF / 印刷怎麼做？
是否需要自己搭建伺服器？

目前可以整理出三種主要方案。

前提：不想額外搭建伺服器

這次的最大前提是：

不想自己準備 Windows Server、IIS、SQL Server，也不想自己維護伺服器。

也就是說，不希望變成這種架構：

Power Apps / Web App
        ↓
自己搭建的 Windows Server
        ↓
自己安裝 SQL Server / PostgreSQL

這種做法雖然技術上可行，但會增加維護成本。

包括：

OS 更新
IIS 設定
防火牆設定
資料庫備份
安全性管理
伺服器監控
障害対応

所以這次更適合考慮 Microsoft 的雲端託管服務。

方案 A：Power Apps + Dataverse

架構

Power Apps
    ↓
Dataverse
    ↓
Power BI / Power Automate / Word Template / Paginated Report

這是最 Power Platform 原生的做法。

Power Apps 負責畫面，Dataverse 負責資料儲存，Power BI 或其他 Power Platform 工具負責報表與分析。

這個方案的特徵

Dataverse 不是傳統意義上的 SQL Database。
它更像是 Power Platform 裡的業務資料平台。

它有資料表、欄位、關聯、權限、View、Business Rule 等概念，但它不是讓你直接把 Access SQL 貼進去執行的地方。

也就是說，原本 Access 裡的：

SELECT ...
FROM ...
INNER JOIN ...
WHERE ...
ORDER BY ...

不能直接整段搬到 Dataverse 裡使用。

在 Dataverse + Power Apps 的世界裡，資料處理通常會變成：

Dataverse View
Power Apps Filter()
Power Apps LookUp()
Power Apps Sort()
Power Automate
Power BI Power Query

優點

方案 A 最大優點是乾淨。

不用自己搭建伺服器
不用管理 DB Server
不用管理 IIS
不用處理 OS 維護
與 Power Platform 整合最好
權限管理與 Microsoft 365 整合自然
適合低程式碼開發

如果系統本身只是簡單 CRUD，例如：

新增資料
修改資料
刪除資料
查詢一覧
簡單狀態管理

那 Dataverse + Power Apps 是很舒服的。

缺點

但對 Access 移行來說，方案 A 的問題也很明顯。

Access 原本的系統通常不是單純資料表，而是有大量：

Access Query
Access SQL
VBA
Form Event
Report
Macro
印刷預覽
多表更新
複雜條件判斷

這些東西搬到 Dataverse 時，很多都要重寫。

尤其是：

Access Query 無法直接移植
VBA 無法直接移植
Access Report 無法直接移植
複雜 SQL JOIN 要改寫
複雜業務邏輯可能會散落在 Power Apps / Power Automate / Dataverse View

所以這個方案的本質是：

資料與畫面可以進 Power Platform，但原本 Access 的邏輯大多需要重新設計。

適合情境

方案 A 適合：

想完全進入 Power Platform 生態
Access 裡的 VBA 不多
複雜 SQL 不多
畫面與流程可以重新設計
重視 Microsoft 365 權限整合
想避免傳統開發

不太適合：

Access Query 很多
VBA 很多
帳票很複雜
多表 Transaction 很多
想盡量保留 SQL 思維

方案 B：Power Apps + Azure SQL Database

架構

Power Apps
    ↓
Azure SQL Database
    ↓
Power BI / 帳票工具

這個方案的核心是：

Power Apps 直接連 Azure SQL Database。

也就是說，Power Apps 不透過後端 API，而是直接對 Azure SQL 的資料表、View 或 Stored Procedure 進行資料操作。

這個方案和 A 的最大差異

方案 A 的資料庫是 Dataverse。
方案 B 的資料庫是 Azure SQL Database。

這個差異非常大。

Dataverse 比較像 Power Platform 原生資料平台。
Azure SQL Database 則是雲端版 SQL Server Database。

所以在 Azure SQL Database 裡，你仍然可以使用比較傳統的 SQL 思維。

例如：

Table
View
Stored Procedure
Index
Transaction
JOIN
GROUP BY
ORDER BY
SQL 權限管理

對於 Access 移行來說，這一點非常重要。

因為 Access 系統裡很多 Query，本質上都接近 SQL。
如果目標資料庫是 Azure SQL，那至少有一部分查詢邏輯可以轉成：

Azure SQL View
Stored Procedure
.NET 查詢 SQL
Power BI Query

而不是全部改成 Power Apps 的 Filter()。

Power Apps 在 B 裡面做什麼？

方案 B 裡，Power Apps 主要負責：

畫面
輸入
按鈕
簡單資料查詢
簡單新增
簡單修改
簡單刪除

例如：

新增一筆受付資料
修改請求人姓名
查詢某個案件一覧
更新狀態欄位

這種操作可以讓 Power Apps 直接對 Azure SQL 做。

概念上類似：

Access Form
    ↓
Access Table / Query

變成：

Power Apps
    ↓
Azure SQL Table / View

優點

方案 B 的優點是兼顧了「不自建伺服器」與「保留 SQL 思維」。

不用自己搭建 SQL Server
不用管理 Windows Server
可以使用 SQL
可以使用 View
可以使用 Stored Procedure
Power BI 連接 Azure SQL 很自然
.NET 開發者容易理解
比 Dataverse 更接近傳統資料庫

對於從 Access 過來的人來說，Azure SQL 的思維會比 Dataverse 更直觀。

缺點

方案 B 的問題是：

Power Apps 直接操作資料庫，適合簡單 CRUD，但不適合把大量複雜業務邏輯塞進畫面裡。

如果按一個按鈕只做：

更新一筆資料
新增一筆資料
刪除一筆資料

那沒問題。

但如果按一個按鈕背後要做：

檢查輸入狀態
查詢主表
查詢明細表
產生流水號
更新 5 張表
新增履歷
改狀態
錯誤時 rollback
輸出帳票資料

那 Power Apps 直接處理就會很痛苦。

不是完全不能做，而是會變得難維護。

最後很容易出現這種狀況：

畫面公式越來越長
Filter / Patch 到處都是
業務邏輯散落在各個按鈕
錯誤處理不集中
Transaction 很難漂亮控制

適合情境

方案 B 適合：

不想自建伺服器
想保留 SQL Database
Access Query 很多
資料表結構比較傳統
Power Apps 主要做簡單 CRUD
Power BI 要直接讀資料庫做報表

不太適合：

按鈕背後有大量 VBA 邏輯
多表更新很多
Transaction 要求高
帳票輸出前資料整理很複雜
業務流程需要集中管理

方案 C：Power Apps + Azure Functions + Azure SQL Database

架構

Power Apps
    ↓
Azure Functions
    ↓
Azure SQL Database
    ↓
Power BI / PDF / Excel / 帳票

這個方案是在 B 的基礎上多加一層後端。

B 是：

Power Apps 直接操作 Azure SQL

C 是：

Power Apps 不直接處理複雜邏輯
而是呼叫 Azure Functions
再由 Azure Functions 操作 Azure SQL

C 和 B 的核心差異

B 的資料流是：

Power Apps
    ↓
Azure SQL

C 的資料流是：

Power Apps
    ↓
Azure Functions
    ↓
Azure SQL

也就是說，C 多了一個「後端業務邏輯層」。

這一層可以用 C# / .NET 寫。

用 Access 來比喻

方案 B 比較像：

Power Apps = Access Form
Azure SQL = Access Table / Query

方案 C 比較像：

Power Apps = Access Form
Azure Functions = VBA / Module / 業務處理
Azure SQL = Access Table

這個比喻最直觀。

Access 裡原本很多按鈕事件可能長這樣：

按下按鈕
    ↓
VBA 檢查資料
    ↓
執行 Query
    ↓
更新多張表
    ↓
開啟 Report

如果搬到 C，就會變成：

Power Apps 按下按鈕
    ↓
呼叫 Azure Function
    ↓
Function 用 C# 執行業務邏輯
    ↓
更新 Azure SQL
    ↓
回傳結果給 Power Apps

Azure Functions 負責什麼？

Azure Functions 可以負責：

複雜查詢
多表更新
Transaction
流水號產生
Access VBA 邏輯移植
錯誤處理
權限檢查
帳票資料整理
PDF / Excel 輸出
與外部系統串接

例如原本 Access 有一個「確定」按鈕，背後做了很多處理：

1. 檢查目前狀態是否允許處理
2. 查詢主資料
3. 查詢明細資料
4. 產生新管理番号
5. 更新主表
6. 新增明細表
7. 新增履歷表
8. 更新狀態
9. 發生錯誤時全部取消

這種就非常適合放在 Azure Functions。

Power Apps 只要做：

使用者按下按鈕
傳入必要參數
等待結果
顯示成功或錯誤訊息

優點

方案 C 最大優點是架構清楚。

Power Apps 專心做畫面
Azure Functions 專心做業務邏輯
Azure SQL 專心存資料
Power BI / PDF 工具專心做報表

這比把所有東西塞在 Power Apps 裡更健康。

尤其是對 Access 移行來說，C 很適合承接原本 VBA 的位置。

原本 Access 是：

Form + VBA + Table + Report

移行後可以變成：

Power Apps + Azure Functions + Azure SQL + 報表工具

職責比較對應。

缺點

方案 C 的缺點是比 B 多一層。

也就是：

需要寫 Azure Functions
需要設計 API
需要處理認證
需要部署 Function
需要維護後端程式碼

雖然它不需要自己搭伺服器，但它仍然是「程式開發」。

所以對完全低程式碼的團隊來說，C 的門檻會比 A、B 高。

適合情境

方案 C 適合：

Access VBA 很多
按鈕背後邏輯很複雜
多表更新很多
需要 Transaction
需要集中管理業務邏輯
想避免 Power Apps 公式爆炸
想用 C# / .NET 重寫核心邏輯
帳票輸出需要後端整理資料

不太適合：

只是簡單 CRUD
團隊完全不想寫程式
業務邏輯很少
只想快速做原型

三個方案的詳細比較

比較項目 方案 A：Power Apps + Dataverse 方案 B：Power Apps + Azure SQL 方案 C：Power Apps + Azure Functions + Azure SQL
是否需要自建伺服器 不需要 不需要 不需要
是否屬於 Power Platform 原生 最原生 部分原生 部分原生
資料庫類型 Dataverse Azure SQL Database Azure SQL Database
是否能直接使用 SQL 基本不能 可以 可以
Access Query 移植性 低 中到高 中到高
VBA 邏輯移植性 低 低到中 高
Power Apps 負責範圍 畫面 + 邏輯 + 資料操作 畫面 + 簡單資料操作 主要負責畫面
複雜業務邏輯放哪 Power Apps / Power Automate / Dataverse Power Apps / SQL Azure Functions
多表 Transaction 不適合 勉強可做，但不理想 適合
帳票輸出 需要重新設計 Power BI / SQL / 外部工具 後端可產 PDF / Excel
開發門檻 低到中 中 中到高
維護性 簡單系統很好，複雜系統可能散亂 中等 複雜系統較好
適合系統類型 輕量業務 App 中等複雜度 CRUD 系統 複雜 Access 業務系統

三個方案的本質差異

可以用一句話理解：

方案 A

全面進入 Power Platform 世界。

資料、畫面、流程都盡量用 Power Platform 的方式重做。

優點是最雲端、最原生。
缺點是 Access 原本的 SQL / VBA / Report 很難直接保留。

方案 B

Power Apps 做畫面，Azure SQL 做資料庫。

這個方案保留了 SQL Database 的思維。
適合想把 Access Table / Query 移到雲端 SQL，但業務邏輯不算太複雜的情況。

方案 C

Power Apps 做畫面，Azure Functions 做 VBA 的替代品，Azure SQL 做資料庫。

這是最接近傳統系統分層的架構。

Power Apps 不需要承擔過多邏輯。
Azure Functions 負責真正的業務處理。
Azure SQL 負責資料。

對複雜 Access 系統來說，這通常是比較現實的架構。

對 Access 移行來說，哪個最合理？

如果原本 Access 系統非常簡單，只是資料輸入和查詢，那方案 A 或 B 都可以。

但如果原本 Access 裡面有大量：

VBA
Access Query
按鈕事件
Report
多表更新
複雜條件判斷
帳票輸出

那不要幻想只靠 Power Apps + Dataverse 就能平滑移行。

那種做法通常會變成：

資料是搬過去了
但業務邏輯全部要重寫
帳票也要重做
複雜查詢也要重新設計

所以更現實的路線是：

第一階段：
Power Apps + Azure SQL Database
先驗證資料表、基本 CRUD、基本查詢

第二階段：
把複雜按鈕、批次處理、多表更新搬到 Azure Functions

第三階段：
帳票部分根據需求選 Power BI、Paginated Report、PDF、Excel Template

也就是從 B 開始，逐步往 C 擴充。

我個人的推薦

如果目標是：

不想額外搭建伺服器
但又不想完全放棄 SQL
而且原本 Access 系統有一定複雜度

那我會推薦：

Power Apps + Azure SQL Database + Azure Functions

但不是一開始就全部做滿。

更實際的做法是：

先用 Power Apps + Azure SQL 做最小驗證
確認資料能搬、畫面能做、基本 CRUD 能跑

然後把複雜處理逐步抽到 Azure Functions

這樣風險最低。

最終結論

這三個方案都不需要自己額外搭建伺服器，但它們的定位完全不同。

方案 A：Power Apps + Dataverse
適合 Power Platform 原生重做，但 Access SQL / VBA 移植成本高。

方案 B：Power Apps + Azure SQL
適合保留 SQL 思維，做基本 CRUD 和查詢，不自建伺服器。

方案 C：Power Apps + Azure Functions + Azure SQL
適合複雜 Access 系統，把原本 VBA / 業務邏輯搬到後端。

如果只是做簡單 App，方案 A 很漂亮。

如果想保留 SQL，又不想搭伺服器，方案 B 很現實。

如果原本 Access 系統有很多 VBA、Query、帳票、多表處理，那最終大概率會走向方案 C。

一句話總結：

不想搭伺服器，不代表只能用 Dataverse。
Azure SQL Database 和 Azure Functions 也是不需要自建伺服器的 Microsoft 雲端服務。
對複雜 Access 系統來說，Power Apps 做前端、Azure SQL 做資料庫、Azure Functions 做業務邏輯，會比硬塞進 Dataverse 更合理。

This article was last edited at