整合多個站台的資料 (用戶端)
許多公司都有區域分公司或機構可收集和處理資料，且必須傳送到中央位置。例如：
可以將存貨資料從本地倉儲的大量伺服器合併到公司總部的一台中央伺服器中。
公司內部獨立的商業部門所產生的資訊，可傳送至中央伺服器。
來源位置分散的訂單處理資訊可以合併。
在某些情況下，資料亦可從中央站台傳送至遠端站台。此資料通常在遠端站台是唯讀資料，如只能在中央站台更新的產品庫存資料表集合。
下圖說明資料在中央站台與遠端位置之間雙向流動的標準狀況：
.gif "正在複寫資料至區域辦事處")
在此圖中，資料首先會流向集線器，然後流向該集線器所服務的區域辦事處。如果該組織沒有中繼層，則資料也可能直接在中央站台和區域辦事處之間流動。
Adventure Works 循環範例
Adventure Works Cycles 是虛構的製造公司，用於示範資料庫概念與案例。如需詳細資訊，請參閱＜AdventureWorks2008R2 範例資料庫＞。
Adventure Works Cycles 在全世界擁有為數眾多的銷售辦事處。每個銷售辦事處都會從其區域銷售人員處收集資料。這些資料會傳送到區域集線器，然後在每個營業日結束時傳送到中央站台。資料也會透過集線器從中央站台傳送到每個銷售辦事處，以便銷售辦事處擁有最新價格和促銷資訊。
這個狀況的一般需求
區域辦事處應用程式通常具有下列特性，適當的複寫方案必須提出因應對策：
資料在中央站台和遠端站台輸入和更新。
遠端使用者必須能夠獨立進行更新，不必連接到中央站台。
由於可能有多位使用者分別更新相同的資料，因此可能產生資料衝突，必須處理。
部分資料應只能在中央站台更新，例如產品價格資料表。
使用者應能視需要或在排程時間同步處理資料。
應用程式必須控制遠端站台能夠保持未同步處理的時間長度。
部分資料表需要篩選，每位使用者才能針對一或多個資料表收到不同的資料。例如，區域辦事處只會收到該辦事處所在區域客戶的連絡資訊。
部分資料在站台之間傳送時，必須視為獨立單位。例如，若遠端使用者傳送訂單到中央站台，必須先認可訂單標頭，再認可訂單詳細內容。
應用程式可能會要求在資料同步處理時，執行自訂商務邏輯。
應用程式可能會要求資料透過網際網路同步處理，而非透過專用連接同步處理。
該業務可以如此組織，即資料透過一或多個中繼層在中央站台和遠端站台之間流動 (如本主題中上圖所示)。
下圖說明與這個狀況相關聯的篩選：
.gif "正在為區域辦事處應用程式進行篩選")
這個狀況要使用的複寫類型
Microsoft SQL Server 使用的是出版業的字眼，來描述複寫系統的元件。元件包含發行者、訂閱者、發行集與發行項，以及訂閱。上圖裡的中央站台是發行者。中央站台端的資料是發行集，而每個資料表則是發行項 (發行項也可以是其他資料庫物件，例如預存程序)。每個集線器是發行集的「訂閱者」，以訂閱的方式接收結構描述和資料。然後該集線器會重新發行資料，區域辦事處會訂閱此資料。如需系統元件的詳細資訊，請參閱＜複寫發行模型概觀＞。
SQL Server 為不同的應用程式需求提供不同類型的複寫：快照式複寫、交易式複寫，以及合併式複寫。這個狀況使用合併式複寫實作最佳，這種複寫適合處理前一區段所述的需求。如需合併式複寫的詳細資訊，請參閱＜合併式複寫概觀＞與＜合併式複寫的運作方式＞。
.gif "重要事項") 重要事項 |
|---|
此狀況可以按照以下兩種方式實作：中央辦事處為「發行者」，遠端辦事處為「訂閱者」，或者中央辦事處為「訂閱者」，遠端辦事處為「發行者」。合併式複寫不支援中央「訂閱者」拓撲。即使所有的變更都發生在遠端站台，仍應將中央辦事處設定為「發行者」，而將遠端站台設定為「訂閱者」。類似的狀況可使用中央「訂閱者」拓撲以交易式複寫實作。如果您的應用程式不要求衝突解決方案，或為每個遠端站台提供唯一資料集的篩選，請考慮使用交易式複寫。如需詳細資訊，請參閱＜整合多個站台的資料 (伺服器)＞。 |
與這個狀況相關的合併式複寫選項
合併式複寫提供數個選項，以處理本主題前面所述的需求。下列清單會列出每一個需求，以及相對的合併式複寫選項。
資料在中央站台和遠端站台輸入和更新。
合併式複寫提供這項功能，不用指定任何其他選項。
遠端使用者必須能夠獨立進行更新，不必連接到中央站台。
合併式複寫提供這項功能，不用指定任何其他選項。
由於可能有多位使用者分別更新相同的資料，因此可能產生資料衝突，必須處理。
合併式複寫針對預期會發生資料衝突的情況提供衝突偵測與解決方案。最好能設計應用程式，以避免衝突；但在不可能這樣做的情況下，您可以選取預設衝突解決機制 (先進先贏) 或使用自訂衝突解決機制。如需詳細資訊，請參閱＜偵測及解決合併式複寫衝突＞。
部分資料應只能在中央站台更新，例如產品價格資料表。
合併式複寫針對那些只應在發行者端更新的資料表，提供僅限下載的發行項。如需詳細資訊，請參閱＜使用僅限下載的發行項最佳化合併式複寫效能＞。
使用者應能視需要及在排程時間同步處理資料。
複寫提供兩種訂閱類型：發送訂閱與提取訂閱。發送訂閱較適合視需要的同步處理。如需訂閱類型與排程同步處理的詳細資訊，請參閱＜訂閱發行集＞與＜同步處理資料＞。
應用程式必須控制遠端站台能夠保持未同步處理的時間長度。
合併式複寫允許您設定訂閱過期期間，以確保所有訂閱者在特定的時間內都已同步處理。如需詳細資訊，請參閱＜訂閱逾期與停用＞。
部分資料表需要篩選，每位使用者才能針對一或多個資料表收到不同的資料。例如，每位銷售人員只收到自己客戶的連絡資訊。
合併式複寫允許您篩選資料行與資料列。資料列篩選可以是靜態或參數化的。只有在建立發行集時才會套用靜態篩選；靜態篩選會產生一個資料集。每次訂閱者同步處理時就會套用參數化篩選；它會為每個訂閱者產生不同的資料集。區域辦事處應用程式通常使用參數化篩選，不過也可以使用靜態篩選。如需詳細資訊，請參閱＜合併式複寫之篩選發行的資料＞。
部分資料在站台之間傳送時，必須視為獨立單位。例如，若遠端使用者傳送訂單到中央站台，必須先認可訂單標頭，再認可訂單詳細內容。
合併式複寫可讓您指定某組相關資料表必須視為一個單位處理。此單位稱為邏輯記錄。如需詳細資訊，請參閱＜使用邏輯記錄分組相關資料列的變更＞。
應用程式可能會要求在資料同步處理時，執行自訂商務邏輯。
合併式複寫允許您指定在同步處理過程中執行的程式碼。這個程式碼可以回應許多的事件，而且能夠存取所同步處理的資料。如需詳細資訊，請參閱＜在合併同步處理期間執行商務邏輯＞。
應用程式可能會要求資料透過網際網路同步處理，而非透過專用連接同步處理。
使用 (SQL Server Compact 3.5 SP2) 時，會透過 HTTP 或 HTTPS 連接同步處理資料。針對其他版本的 SQL Server，您可以使用 Web 同步處理 (需要 HTTPS)。如需詳細資訊，請參閱＜合併式複寫的 Web 同步處理＞。
該業務可以如此組織，即資料透過一或多個中繼層在中央站台和遠端站台之間流動。
合併式複寫可以透過重新發行配合此需求，透過這種方法，中央「發行者」會將資料發行到一或多個「訂閱者」，然後再將其發行到其他「訂閱者」。如需詳細資訊，請參閱＜重新發行資料＞。
實作這個狀況的步驟
若要實作這個狀況，您必須先建立發行集與訂閱，然後初始化每個訂閱。按一下下列的連結，以取得有關每個步驟的詳細資訊：
在初始化訂閱，而且資料在發行者與訂閱者之間流動之後，您可能需要參考下列主題，以取得一般管理與監視工作的資訊：