有時候出于某些特定的原因，需要在服務器端與客戶端之間進行數(shù)據(jù)的同步。如下圖所示，某個公司在各地有銷售辦事處。為了便于管理，在每個銷售辦事處都設置了SQL Server客戶端應用程序。每天晚上總公司的數(shù)據(jù)庫服務器需要與各自的辦事處客戶端之間的數(shù)據(jù)進行同步。這主要是通過服務器與客戶端之間的數(shù)據(jù)復制功能來實現(xiàn)的。在SQL Server中有這方面現(xiàn)成的解決方案，實現(xiàn)起來也比較簡單。為此對于這個具體的實現(xiàn)，筆者就不做過多闡述了。筆者現(xiàn)在要就講的是，在設計并實現(xiàn)這個解決方案的時候，需要注意哪些問題。
注意事項一：按計劃同步與安需同步要一起實現(xiàn)。
這個解決方案的關鍵點就是如何保證客戶端與服務器之間數(shù)據(jù)的同步問題。一般來說，這個同步是有計劃的，是自動完成的。如每天晚上12點自動與總公司的數(shù)據(jù)庫服務器進行數(shù)據(jù)同步。把客戶端的數(shù)據(jù)傳遞給服務器，然后再把數(shù)據(jù)庫中最新的數(shù)據(jù)下載下來。這個動作往往不需要手工去干預，只要剛開始設置好，這個同步工作就會自動完成。
但是，除了可以根據(jù)計劃來實現(xiàn)同步的話，有時會也需要能夠按需來進行同步。如在2009年6月1日晚上11點實現(xiàn)同步后，在6月2日早上7點之前總公司定義好了最新的價格。6月2日以后的價格要按這個最新的價格表執(zhí)行。此時在總公司服務器處，就需要強制更新各個客戶端的價格。這個就在計劃之外了。另外需要注意的是，根據(jù)計劃同步的時候，往往同步的是全部的數(shù)據(jù)，包括銷售數(shù)據(jù)、庫存量、新增加會員信息等等。而按需實現(xiàn)同步的話，往往只是針對特定的表，如銷售價格等等。所以在按需同步時，必須要能夠?qū)崿F(xiàn)根據(jù)特定表來進行同步。如果在按需同步時，同步不必要的數(shù)據(jù)，則可能需要比較長的時間。而按需同步往往是用來針對一些特殊的情況，時間比較緊。所以只針對特定的表進行同步，以減少同步的時間，這是非常必要的，也是非常實際的一個問題。
注意事項二：可以通過多種方式與服務器實現(xiàn)數(shù)據(jù)同步。
一般來說，通過VPN隧道在客戶端與服務器之間實現(xiàn)數(shù)據(jù)的復制，這是比較可行的方案。因為在客戶端與服務器端之間建立VPN隧道，不僅可以增加數(shù)據(jù)的安全，而且還可以提高復制的效率。其整個同步過程所花費的時間是比較短的。但是其代價也是比較高的。如果辦事處與總公司的位置不是很遠，如在同一個城市，則對企業(yè)來說，通過VPN隧道來實現(xiàn)客戶端與服務器端數(shù)據(jù)的同步就顯得有點浪費。
所以，在設計這個解決方案的時候，數(shù)據(jù)庫管理員最好能夠考慮一下，能否采用其他一些更加便宜的方式來實現(xiàn)同步。如直接通過internet來實現(xiàn)同步。雖然這個方式可能會發(fā)生數(shù)據(jù)泄露的危險，而且速度也比較慢。但是價格比較便宜。對于一般的企業(yè)來說，如服裝企業(yè)在同城設立銷售點的話，采用這個方式來實現(xiàn)同步也已經(jīng)足夠了。為此在設計客戶端與服務器端數(shù)據(jù)同步時，數(shù)據(jù)庫管理員需要向客戶說明各種同步渠道的差異，并根據(jù)客戶的要求來實現(xiàn)。而不能夠想當然而，認為VPN隧道不錯，就采用這個同步渠道。
注意事項三：設置更新源。
由于各地的辦事處都需要向服務器提出更新的需要。不過為了提高數(shù)據(jù)的準確性，在服務器上必須能夠設置，哪些內(nèi)容只可以在服務器上進行更新。如通常情況下，產(chǎn)品的價格只能夠有服務器來更新。像KFC各地銷售的價格都是統(tǒng)一的。所以各地銷售點是不能夠更新服務器方的價格表。如果需要提價的話，往往是在服務器端調(diào)整價格，然后再把這個價格信息強制更新到各地的銷售辦事處。所以某些數(shù)據(jù)應當只在服務器方進行更新。
為此，在部署這個方案時，數(shù)據(jù)庫管理員應該協(xié)同企業(yè)的管理人員，確定到底哪些數(shù)據(jù)只能夠在數(shù)據(jù)庫服務器方進行更新。如果可行的話，數(shù)據(jù)庫管理員還可以給企業(yè)一些建議。即可以根據(jù)自己的經(jīng)驗，把需要在服務器方進行更新的內(nèi)容列出來。這些內(nèi)容有產(chǎn)品基本信息、產(chǎn)品價格、促銷方案等等。然后供企業(yè)用戶選擇。這會讓企業(yè)用戶能夠更加迅速、準確的選擇出相關的內(nèi)容。當然，如果企業(yè)平時管理比較規(guī)范的話，那么肯定也有這方面的書面資料。此時對于數(shù)據(jù)庫管理員來說可能工作起來更加的方便。無論如何，在部署這個解決方案時，數(shù)據(jù)庫管理員必須向企業(yè)客戶確認這方面的內(nèi)容。不然的話，到時候出問題，數(shù)據(jù)庫管理員可要吃不了兜著走了。
注意事項三：要多某些記錄進行刷選。
不同的客戶端，從同一個表中獲取數(shù)據(jù)，但是其獲取的紀錄可能是不同的。如一個中式快餐店，在各地辦了很多分店。其為了招攬顧客，會不斷的推出新的品種。不過新產(chǎn)品剛剛推出的時候，往往只有在幾個特定的門店有的賣。企業(yè)希望通過這種方式來判斷顧問對新產(chǎn)品的接受程度。如果反響好的話，才會在各地的門店中推廣。
這個需求說出來簡單，但是在系統(tǒng)的實現(xiàn)上有一定的難度。具體來說，就是要求客戶端與服務器之間在進行數(shù)據(jù)同步的時候，要能夠根據(jù)門店代碼的不同，進行記錄的刷選，把某些產(chǎn)品記錄過濾掉，以免造成不必要的麻煩。這在SQL Server數(shù)據(jù)庫上也是可以實現(xiàn)的，配置起來不是很復雜。在實現(xiàn)過程中，其難點是管理方面的問題。即企業(yè)需要根據(jù)實際情況，定義好相關的過濾規(guī)則。而企業(yè)平時主要是依靠口頭管理，缺乏相關的規(guī)則。為此在這個規(guī)則的定義上，就遇到了麻煩。
通常情況下，這個流程是各地連鎖店自己申請或者有企業(yè)總部指定，然后把新產(chǎn)品在這幾個門店試賣。從技術的角度來講，只是在連鎖店信息中加入一個字段，然后再過濾條件上加入一個判斷條件即可。為此數(shù)據(jù)庫管理員還需要幫助企業(yè)確認相關的業(yè)務邏輯。往往著是實現(xiàn)這個需求的關鍵。如果這個業(yè)務邏輯定義的比較嚴格，而且企業(yè)會嚴格執(zhí)行的話，那么后續(xù)基本上不需要調(diào)整。而如果企業(yè)沒有明確的業(yè)務邏輯，而純粹是憑“靈感”的話，那么后續(xù)調(diào)整可能會比較多。對于這一點，數(shù)據(jù)庫管理員自己不僅需要心中有數(shù)，而且還需要向企業(yè)說明這個問題，讓他們認識到這個事件的嚴重性。#p#分頁標題#e#
注意事項四：必須控制遠程站點保持不同步狀態(tài)的時間。
為安全起見，相關應用程序還必須控制遠程站點保持不同步狀態(tài)的時間。簡單的說，就是當某個客戶端在規(guī)定的時間內(nèi)沒有進行數(shù)據(jù)同步(如網(wǎng)絡異常導致同步失敗)，那么該采取什么措施?如可以設置一個寬限期，第一次同步失敗后沒有關系，但是不能夠連續(xù)三次同步失敗。如果控制的比較嚴格，如同步失敗后，馬上就鎖住客戶端，不允許相關的應用程序再連接到這個客戶端。一般來說，對于即時性要求比較高的企業(yè)，如彩票行業(yè)、銀行等等都會有類似的要求。
可見，當客戶端不及時同步該如何處理，這也是因企業(yè)而異的。從SQL Server數(shù)據(jù)庫角度來講，可以設置不同的規(guī)則來處理這件事情。如可以即時鎖住客戶端，也可以給管理員提供警告，或者給與一個寬限期。現(xiàn)在主要的問題是，企業(yè)要確定自己所需要的管理方式，并且在短時間內(nèi)不會改變。然后，數(shù)據(jù)庫管理員就可以根據(jù)企業(yè)的要求，在數(shù)據(jù)庫客戶端與服務器中進行相關的設置。通常情況下，為了數(shù)據(jù)能夠及時的同步，都需要在客戶端采取措施控制遠程站點保持不同步狀態(tài)的時
