哪種類型的 SQL Server 複製適合我們的場景？合併還是交易？
背景
在我們目前的設置中，我們在遠端託管的 Web 伺服器上有一個 SQL Server 2005 實例。我們還有另一個（非 MSSQL）數據庫，用於我們的 POS 系統，當事情（例如產品資訊）發生變化時，它會自動更新 Web 伺服器。這有兩個問題：
- 連接可能很慢，因此我們無法輕鬆使用程式碼的本地副本
- 有時我們無法訪問 Web 數據庫（即使該站點仍然可以執行），這會導致 POS 系統掛起。
我正在努力的解決方案是在公司總部本地設置第二個 SQL Server 實例（2005 或 2008），將 POS 系統指向它，並使用某種形式的複制來同步它們之間的更改。但是，我不知道我們應該使用合併複製還是事務性。
題
合併或事務複製會更好地為我們服務嗎？
我們的要求是：
在總部更新產品數據並將其以只讀方式推送到網站。
更新網站訂單數據並推送至總部
將總部的小改動同步回網站（訂單狀態）
當無法進行通信時，兩端的可用性都不會中斷
即總部仍然可以訪問和更新我們的副本，網站可以更新它，當通信恢復時，更改將被同步。
*（可選）*一種在刪除複製的情況下製作 HQ 數據庫副本的簡單方法，用於程式碼測試目的。
哪一種更符合我們的要求？
一些想法。在我看來，如果複製是你最終的結果，你可能會選擇幾個選項。首先要注意 - 複製不應該只在生產中配置和啟用/使用，除非您有一些經驗。對於更重要的工作負載和更繁忙的系統，這一點變得更加真實。如果複製不當，複製可能會導致頭痛。我會投資於指導/培訓/諮詢，以幫助您從那些已經被錯誤燒傷的人的道路上走下去。
那就是說。在我看來，您的要求似乎沒有任何需要同步或合併的雙向更改。看起來你有很多東西需要朝著一個方向發展。訂單永遠不會在本地收到，只會在網站上收到。訂單狀態永遠不會在網站上生成，只會被消費等。
如果是這樣的話——這對我來說聽起來像是事務複製。當您需要多個可以同時進行更改和接收更改的版本時，合併更多。陳舊的微軟範例仍然有效——一群銷售人員都擁有一個本地應用程序來進行潛在客戶管理和一個大型中央伺服器。他們可以在家庭辦公室獲得潛在客戶並獲取數據，然後他們可以離線工作並同步他們的更改。使用 Merge，您必須處理衝突（如果在兩個地方修改相同的數據，誰會獲勝？）當您在一個方向上進行更改時，事務性更多使用（但您也可以在這裡雙向進行）。
您可以將複製設置為將各種表作為文章包含或不包含在出版物中。
幾個連結可以為您提供更多資訊：
現在，如果您有可以更新每個數據並且需要“合併”的數據，那麼合併可能是一個更好的答案。當我使用複制時——不過，我更願意盡可能地接近事務。它更易於管理，如果您不需要它，也無需擔心衝突解決。
根據您的音量 - 如果它足夠低 - 以及您的延遲 - 如果一些延遲時間是可以接受的 - 您可能還會考慮更多程序化或 ETL 之類的東西。也許暫存數據並分批發送。當一側的數據發生變化時發送消息等。