Power Platform 中的 Segmented Table 到底是什麼？Managed Solution 不是已經能升級了嗎？

| PowerPlatform | 1 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/1342

第一次看到 Segmented Table 這個詞，很容易把它理解成資料庫裡的「分區表」「分片表」，甚至以為 Dataverse 會把一張表拆成幾段保存。

其實完全不是。

在 Power Platform 裡，更準確的名稱是：

Table Segmentation，表元件分段打包。

它不會改變 Dataverse 的資料儲存方式，也不會把表裡的 Records 分割。它只是決定：

將一張 Dataverse Table 加入 Solution 時，是把整張表的所有元件都放進去，還是只放這次新增或修改的幾個元件。

Microsoft 對 Table Segmentation 的定義也是：在發布 Solution 更新時，只包含本次更新的表元件，例如欄位、Form 和 View，而不是把整張表的所有資產全部打包。(Microsoft Learn)

一、先看一個最直觀的例子

假設生產環境，也就是本番，已經有一張案件表：

crx_case

這張表目前包含：

30 個 Columns
5 個 Views
3 個 Forms
8 個 Relationships

現在我們在 DEV 環境中新增了一個欄位：

crx_priority

接下來要把這個修改發布到本番。

這時有兩種打包方式。

方式一：把整張表放進 Solution

Solution 中包含：

crx_case
├─ 所有 Columns
├─ 所有 Views
├─ 所有 Forms
├─ 所有 Relationships
├─ Business Rules
└─ Table Metadata

也就是 Power Apps 中的：

Include all objects

方式二：只加入新增的欄位

Solution 中只包含：

crx_case
└─ crx_priority

也就是：

Edit objects
└─ Columns
   └─ crx_priority

第二種做法，就是 Segmented Table。

表本身還是原來的 crx_case，並沒有被切成幾張表；只是 Solution Package 裡只裝入了這次真正需要部署的元件。

二、Table 到底可以被「Segment」哪些內容？

Dataverse Table 並不是一個不可拆分的單一物件。

一張 Table 底下還包含很多獨立的 Solution Components，例如：

Table
├─ Columns
├─ Relationships
├─ Keys
├─ Forms
├─ Views
├─ Charts
├─ Business Rules
└─ Table Metadata

在把既有 Table 加入 Solution 時，Power Apps 目前主要提供以下選項：

選項 含義
No objects selected 只加入最基本的 Table 識別資訊
Edit objects 自己選擇 Columns、Forms、Views、Relationships 等元件
Include table metadata 只包含 Auditing、Change Tracking、Duplicate Detection 等表屬性
Include all objects 包含整張表的所有元件和 Metadata

其中，選擇 Edit objects，只加入部分元件，就是最典型的 Table Segmentation。(Microsoft Learn)

三、為什麼需要 Segmented Table？

最常見的疑問是：

Managed Solution 不是本來就能 Update 或 Upgrade 嗎？為什麼還要搞一個 Segmented Table？

原因是：

Managed Update／Upgrade 負責「怎麼安裝」，Table Segmentation 負責「安裝包裡裝了什麼」。

這是兩個不同層面的功能。

可以把它理解成：

Table Segmentation
= 包裹裡放哪些元件

Managed Solution
= 包裹以受管理形式發布

Update / Upgrade
= 包裹到達本番後如何套用

所以實際流程可能是：

DEV 中修改 Unmanaged Solution
        ↓
只選擇本次修改的 Table Components
        ↓
Export as Managed
        ↓
Import 到 TEST / UAT / PROD
        ↓
選擇 Update 或 Upgrade

Segmented Table 並不是用來取代 Managed Solution，而是控制 Managed Solution 的內容範圍。

四、它是不是專門為了防止本番其他人修改？

這個理解有一部分是對的，但不完整。

假設本番中有另一個團隊、另一個 Solution，或者某個人修改了同一張表的 Main Form。

而你這次其實只新增了一個欄位，卻把整張 Table 的所有 Form、View 和 Relationship 都打包進 Solution。

那麼你的部署就可能同時為這些沒有修改過的元件引入新的 Solution Layer。

例如：

本次真正修改：
└─ crx_priority Column

實際打包內容：
├─ crx_priority Column
├─ Main Form
├─ Active Cases View
├─ Quick Find View
└─ 多個 Relationships

結果就會變成：

明明只想增加一個欄位，卻把 Form、View 和 Relationship 也捲入了這次發布。

Microsoft 明確警告，不應把沒有新增或修改的表元件放進更新包。因為不必要的元件可能建立額外的 Solution Layer，使下面既有的自訂失效，並產生不必要的 Solution Dependencies。(Microsoft Learn)

所以，Segmented Table 確實能降低多人、多 Solution、多供應商之間互相干擾的風險。

但它的核心目的不是專門保護「本番另一位修改者」，而是：

讓一次部署只影響這次真正變更的元件。

即使沒有任何人在本番手動修改，減少無關 Layer 和 Dependency 仍然有價值。

五、直接修改本番時，Segmented Table 也不會自動合併衝突

還有一個常見誤解：

DEV 和 PROD 都有人修改，使用 Segmented Table 後，系統是不是可以自動把兩邊的修改合併？

不是。

Segmented Table 只是縮小部署範圍，不是 Git Merge，也不是 Schema Compare。

如果有人直接在本番修改 Managed Component，通常會在上方形成一個 Unmanaged Active Layer。這時即使重新匯入 Managed Solution，新版本的設定也可能不生效，因為本番的 Active Layer 仍然位於最上方。(Microsoft Learn)

例如：

最上層：本番直接修改的 Unmanaged Active Layer
中間層：你新匯入的 Managed Solution
底層：舊 Managed Solution

真正決定執行時行為的，通常是最上層。

所以正確的 ALM 流程仍然應該是：

DEV 是唯一修改來源
        ↓
Export Managed Solution
        ↓
部署到 TEST / UAT / PROD

而不是：

DEV 有人修改
PROD 也有人直接修改
最後依賴 Segmented Table 自動合併

Microsoft 也建議在開發環境中使用 Unmanaged Solution 進行開發，再把它匯出為 Managed Solution，部署到測試、UAT 和生產等下游環境。(Microsoft Learn)

六、Segmented Table 和 Update／Upgrade 的真正關係

這一點非常重要。

Update

使用 Managed Solution 的 Update 時：

新版 Solution 中沒有包含的舊元件
→ 通常不會被刪除

所以，對於單純增加欄位、修改 View 或修改 Form 的日常發布，Update 通常比較安全，也比較快。

Upgrade

使用 Upgrade 時：

舊版本 Solution 中存在
但新版 Solution 中已經不存在的元件
→ 可能被刪除

Upgrade 的目的是讓目標環境最終更接近新版 Solution 的定義，包括清理已經從新版移除的舊元件。(Microsoft Learn)

因此必須注意：

如果你為了做 Segmentation，把舊版 Solution 中原本存在的元件從新版移除了，卻又使用 Upgrade，這些元件可能會被當成「已從新版刪除」而清理。

所以不能簡單理解為：

只改一個欄位
→ 隨便做一個只包含欄位的包
→ 一律選 Upgrade

更穩妥的判斷是：

只是新增或修改元件
→ 優先考慮 Update

確實需要刪除舊元件
→ 使用 Upgrade

Segmented Table 控制的是「哪些元件參與更新」；Upgrade 還包含「清理舊版本元件」的語義，兩者不能混為一談。

七、如果整個 Dataverse 只有我們自己操作，還需要嗎？

假設你的系統符合以下條件：

只有一個開發團隊
只有一個主要 Solution
Custom Table 都由這個 Solution 建立
沒有其他 Solution 修改相同元件
不允許直接修改本番
DEV 是唯一可信的結構來源

那麼答案是：

可以不用把 Segmented Table 當成必須嚴格執行的核心規則。

你可以直接在 DEV 的 Unmanaged Solution 中修改，然後：

增加 Solution Version
        ↓
Export as Managed
        ↓
Import 到本番
        ↓
選擇 Update 或 Upgrade

即使 Solution 中包含整張 Custom Table，通常也能正常運作。

但是「不強制使用」不等於「完全沒有價值」。

即使只有一個團隊，Segmented Table 仍然可以：

  • 減少 Solution Package 大小；

  • 減少不必要的 Dependencies；

  • 避免誤帶沒有修改的 Form 和 View；

  • 縮小一次發布的影響範圍；

  • 讓 Code Review 和部署內容更清楚；

  • 為未來拆分多個 Solution 預留空間。

Microsoft 對已經存在於下游環境中的 Table，仍然建議只加入本次實際更新的 Table Objects。(Microsoft Learn)

因此更準確的結論是：

只有一個團隊時，使用整張 Table 的風險會低很多，可以簡化流程；但 Table Segmentation 仍然是更精細的 ALM 最佳實踐。

八、什麼情況一定不要做 Segmentation？

最典型的情況是：

目標環境裡根本還沒有這張 Table。

例如，你在 DEV 中新建了一張：

crx_casehistory

而本番尚未存在這張表。

這時應該選：

Include all objects

因為本番需要建立完整的：

Table
Columns
Primary Column
Relationships
Keys
Forms
Views
Metadata

如果目標環境中還不存在這張 Table，卻只選其中幾個 Columns，匯入時很可能出現 Missing Dependency。

Microsoft 也明確說明：對從未匯入目標環境的新 Custom Table，不能進行 Segmentation，必須選擇 Include all objects。(Microsoft Learn)

九、實際工作中可以直接套用的判斷方式

場景 建議
本番不存在的新 Custom Table Include all objects
既有 Table 新增一個 Column Edit objects，只選新 Column
修改一個 Form 只選該 Form，以及必要的依賴元件
修改一個 View 只選該 View
修改 Auditing、Change Tracking Include table metadata
修改 Account、Contact 等共用標準表 強烈建議 Segmentation
多團隊、多 Solution 共用同一張表 強烈建議 Segmentation
單團隊、單 Solution、禁止修改本番 可以簡化，整表更新通常也可行
刻意刪除舊欄位或舊元件 從來源 Solution 移除後使用 Managed Upgrade
做災難恢復或完整快照 不應只做 Segmentation，應保存完整結構

十、Segmented Table 和備份快照不是一回事

對於日常 ALM 部署，Segmented Table 的目標是：

只發布本次變更

但對於 Dataverse 快照或災難恢復，目標是：

表被刪除時也能完整重建

所以備份工具不應只保存某幾個 Columns，而應盡可能保存：

完整 Table Metadata
完整 Columns
Relationships
Keys
Choices
Forms
Views
業務 Records
Lookup 關係
N:N 關係
File / Image

因此：

Segmented Solution
= 日常部署策略

Full Snapshot
= 備份與恢復策略

兩者的目的正好相反。

十一、常見誤解總結

誤解一：Segmented Table 是一種特殊資料表

不是。

它只是 Solution 的元件選擇方式，與 Dataverse 實際資料儲存方式無關。

誤解二：只有本番有人修改時才需要

不完全是。

多人修改會讓它更重要，但它本身也用來減少無關 Solution Layers 和 Dependencies。

誤解三：用了 Managed Upgrade 就不需要 Segmentation

不是。

Segmentation 決定包裹內容，Upgrade 決定包裹如何安裝和清理舊元件。

誤解四：Segmented Table 可以自動合併 DEV 和 PROD

不能。

它不是版本控制，也不是衝突合併工具。

誤解五：新建 Table 也應該只選幾個欄位

錯誤。

如果目標環境還沒有該 Table，必須包含完整 Table Objects，否則可能缺少依賴。

結語

Segmented Table 可以用一句話概括：

當目標環境已經存在某張 Dataverse Table 時，只把本次新增或修改的 Column、Form、View、Relationship 等元件放進 Solution，而不是把整張 Table 的所有內容全部打包。

它出現的目的，不只是保護本番其他人的修改，更是為了：

縮小部署範圍
減少無關 Solution Layers
減少 Dependencies
避免誤帶未修改元件
降低多 Solution 互相影響的風險

對於單一團隊、單一 Solution、完全禁止修改本番的小型系統，不必把它搞得過度複雜，完整 Managed Solution 更新通常已經足夠實用。

但對於標準表、共用表、多團隊、多 Solution 或精細化 ALM，Segmented Table 就是一個非常值得遵守的部署習慣。

This article was last edited at