從 Access 移行到 Power Platform，最合理的架構其實不是「全搬到 Dataverse」
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/1304
最近在研究一個既存的 Access 系統移行問題。
這個系統不是單純的資料庫，而是典型的 Access 業務系統：
Access Form
VBA
Query
Report
印刷プレビュー
帳票輸出
也就是說，它不是只有資料表，而是一整套 Application 本體。
所以問題來了：
如果要把這種 Access 系統移行到 Power Platform，最合理的架構是什麼？
我的結論是：
不要把整個 Access 系統硬塞進 Dataverse。
最合理的方式應該是：
Power Apps 做前端，.NET API 做後端，SQL 系資料庫做核心資料庫，Power BI / Paginated Report 做帳票。
一、為什麼不能單純「Access → Dataverse → Power Apps」
很多人一聽到 Power Platform，第一反應可能是：
Access 的表 → Dataverse
Access 的畫面 → Power Apps
Access 的帳票 → Power BI
看起來很合理。
但實際上，這種想法有很大的風險。
因為 Access 系統通常不是單純的資料庫，而是把很多東西混在一起：
畫面邏輯
按鈕事件
VBA 函數
Access SQL
查詢 Query
Report 設計
印刷 Preview
資料檢查
業務流程控制
如果只是把資料表搬到 Dataverse，原本的 VBA、Access Query、Report 都不會自動變成 Power Platform 可用的東西。
結果就會變成：
VBA 要重寫
Access SQL 要重寫
Report 要重做
印刷功能要重新設計
複雜查詢要改成 Power Fx / Filter / Dataverse View
這就不是「移行」，而是「重新開發」。
二、我認為最合理的架構
我會推薦這種架構：
Power Apps Canvas / Model-driven App
↓
Custom Connector
↓
.NET 8 Web API / Azure Functions
↓
PostgreSQL / Azure SQL
↓
SQL View / Stored Procedure / Query Layer
↓
Power BI / Paginated Report / PDF Export
也就是：
Power Apps：負責畫面
.NET API：負責業務邏輯
PostgreSQL / Azure SQL：負責核心資料
Power BI / Paginated Report：負責帳票與 PDF
簡單講：
Power Apps 當皮，.NET 當腦，SQL 當心臟，Power BI / Paginated Report 當印表機。
三、Power Apps 應該負責什麼？
Power Apps 適合做的是操作畫面。
例如：
検索条件入力
一覧表示
詳細表示
新增
修改
刪除
狀態更新
按鈕操作
也就是讓使用者可以很快地操作資料。
例如畫面上可以有：
受付番号輸入框
請求人輸入框
税目下拉選單
事件種別下拉選單
検索按鈕
PDF出力按鈕
這些都很適合 Power Apps。
但是，Power Apps 不適合承接大量複雜業務邏輯。
例如：
多表 JOIN
複雜條件判斷
大量 Access SQL
VBA 函數移植
批次處理
帳票資料整形
印刷前檢查
這些如果硬寫在 Power Fx 裡，後期會非常難維護。
四、.NET API / Azure Functions 應該負責什麼？
原本 Access 裡面的 VBA 邏輯，應該移到後端。
例如原本 Access 裡可能有：
DBFunc
FormFunc
ReportFunc
DateFunc
DataConvert
各種按鈕 Click 事件
各種查詢前處理
這些東西不要硬塞到 Power Apps 裡，而是應該移植到：
.NET 8 Web API
或 Azure Functions
例如可以設計成：
GET /api/cases/search
GET /api/cases/{id}
POST /api/cases/{id}/status
POST /api/reports/misai-list/pdf
POST /api/reports/progress/pdf
Power Apps 只需要呼叫 API。
這樣的好處是：
業務邏輯集中管理
SQL 可以保留原本思路
可以寫單元測試
效能比較可控
以後不會被 Power Apps 綁死
Power BI 也能共用同一套資料邏輯
五、資料庫應該用 Dataverse 嗎？
這裡是最重要的判斷點。
如果是簡單業務資料，Dataverse 當然可以用。
但是如果這是一套 Access 老系統，而且裡面有大量查詢、帳票、JOIN、條件判斷，那我不建議把核心資料全部放 Dataverse。
我會更推薦：
PostgreSQL
或 Azure SQL
原因是：
可以直接使用 SQL
可以建立 View
可以建立 Stored Procedure
索引和效能比較好控制
.NET 後端操作方便
Power BI 可以直接讀 View
帳票資料整形比較容易
Dataverse 不是不能當資料庫，而是它不是傳統 SQL DB。
如果原系統非常依賴 Access SQL，那麼移到 Dataverse 後，很多地方都不能直接沿用。
六、Dataverse 在這個架構中的角色
我認為 Dataverse 不一定要當主資料庫。
它更適合當 Power Platform 的整合層。
例如可以放：
Power Apps 用的設定資料
簡單 Master
使用者權限對應
審批流程狀態
少量低複雜度資料
Solution 管理用資料
但是核心業務資料，例如：
事件處理資料
進行狀況
受付番号
請求人
税目
事件種別
帳票明細
大量查詢用資料
我會放在 SQL 系資料庫裡。
也就是說：
Dataverse：輔助
SQL：核心
這樣會比較現實。
七、帳票和 PDF 不應該硬塞進普通 Power BI
Access 系統通常很重視帳票。
例如：
印刷プレビュー
固定格式帳票
明細表
合計欄
頁碼
每頁列數控制
PDF 輸出
這種東西如果用普通 Power BI Report 做，會比較痛苦。
普通 Power BI 比較適合：
Dashboard
圖表
分析報表
互動式篩選
但如果是日本業務系統常見的「印刷帳票」，我會更推薦：
Power BI Paginated Reports
或
.NET 後端產 PDF
Paginated Report 比較接近 Access Report 的定位。
如果帳票格式很固定，甚至可以直接由 .NET 後端產 PDF，Power Apps 只負責觸發下載。
八、最終架構圖
整理起來，最合理的架構是：
[使用者]
↓
[Power Apps]
├─ 検索画面
├─ 入力画面
├─ 一覧画面
├─ 詳細画面
└─ PDF出力ボタン
↓
[Custom Connector]
↓
[.NET API / Azure Functions]
├─ VBA 邏輯移植
├─ SQL 查詢
├─ 資料檢查
├─ 業務流程控制
├─ 批次處理
└─ 帳票資料生成
↓
[PostgreSQL / Azure SQL]
├─ Tables
├─ Views
├─ Stored Procedures
└─ Audit Log
↓
[Power BI / Paginated Report / PDF]
├─ 帳票
├─ PDF
└─ 印刷
這樣每個技術都做自己擅長的事情。
九、可以怎麼向上面說明？
如果要用比較正式的日文說明，可以這樣寫：
この Access システムは単なるデータベースではなく、
VBA・クエリ・フォーム・帳票が一体化した業務アプリケーションです。
そのため、Dataverse へテーブルを移行するだけでは、
既存の処理ロジックや帳票機能を再現することはできません。
Power Apps は画面および操作入口として利用し、
業務ロジックは .NET API または Azure Functions、
データは PostgreSQL または Azure SQL、
帳票は Power BI Paginated Reports または API 側の PDF 出力で分担する構成が現実的です。
中文意思就是：
這個 Access 系統不是單純的資料庫，而是 VBA、查詢、畫面、帳票一體化的業務應用。
所以不能只把表搬到 Dataverse 就期待整個系統能重現。
比較現實的做法是讓 Power Apps 負責畫面，.NET API 負責業務邏輯，SQL 資料庫負責核心資料，Power BI / Paginated Report 負責帳票和 PDF。
十、結論
這次移行最重要的不是「要不要用 Power Platform」，而是要弄清楚：
Power Platform 應該負責哪一層？
我認為最合理的分工是：
Power Apps：畫面
.NET API / Azure Functions：業務邏輯
PostgreSQL / Azure SQL：核心資料庫
Power BI / Paginated Reports：帳票與 PDF
Dataverse：必要時作為輔助整合層
不要把 Power Apps 當成 Access 的完整替代品。
也不要把 Dataverse 當成傳統 SQL Server 或 PostgreSQL 的替代品。
Power Platform 很強，但它不是萬能的。
尤其是面對這種老式 Access 業務系統時，最危險的做法就是：
表搬到 Dataverse
畫面用 Power Apps 重畫
邏輯用 Power Fx 硬寫
帳票用 Power BI 硬湊
這樣最後很可能變成：
原本 Access 裡可以做的事，
移行後每一件都要重新想辦法。
所以最現實的架構應該是混合式架構。
不是「全部 Power Platform」，而是：
Power Platform + .NET + SQL + 報表工具 的分層架構。
這樣才比較像真正的系統移行，而不是把一台傳真機硬改造成 iPad。
This article was last edited at