2013-05-28 190 views
1

我需要更改三個表中的數據(更新一些現有的行,添加一些新的,刪除一些舊的)。我需要它在一瞬間完成。問題是數據需要手動更改,可能需要一些時間才能完成。所以我打算使用beta服務器來進行更改。問題是:如何用另一個數據庫的數據更新生產服務器?從另一個數據庫更新表

我的解決辦法:從公測服務器轉儲數據和生產恢復。
瑕疵:我將不得不首先刪除生產中的所有數據,並且由於外鍵(我可以先關閉鍵,但有沒有辦法避免它)?

我找到了similar question,其中一個答案建議使用dblink命令。我想我可以寫更新聲明,但這似乎仍然有點矯枉過正。

編輯(補充說明):
有生產服務器(姑且稱之爲Production),並有開發服務器(姑且稱之爲Beta)。所以我需要在生產中更改一些數據(3個互連的表,它們也可以從DB中的其他表引用)。準確地說 - 這些表格包含學習計劃 - 主題,主題組和子主題。有些引用這些元素的寄存器。但是我需要在一瞬間完成這些更改(意思是:通過SQL腳本)。爲了做到這一點,我將使用Beta服務器 - 它包含生產數據庫的副本(在某個時刻完成,不需要實時同步)。因此,我將在Beta服務器上的3個表中更新數據,並且需要將這些數據移至生產。

+0

能否請您詳細解釋問題?例如:你想改變的表的數量。您想要包含的數據存在於同一個表結構中的另一個數據庫中嗎?請詳細說明。 – RGV

+0

我已經更新了我的Q. – Wiktor

+0

這個問題是關於(i)使單元格中的值更改的過程變得容易的工具(例如,一個可以顯示邏輯分組中的單元格的上端和下端該表或應用篩選器以找到需要更改的行)'OR'(ii)在對其客戶的副本進行更改後同步prod數據庫的方法? – Stoleg

回答

1

您的策略取決於您識別獨一無二的行的能力。

如果可以創建一個唯一的密鑰每一行(不是必要的,你已經創建了一個UNIQUE約束),則:

  1. 所有數據複製到Beta。通過做出的更改標記爲受影響的行或創建NEWUPDATEdDELETEd表。
  2. 僅將標記行復制到Production
  3. 應用更改。如果你能發現Production行自你的副本以來已經發生了變化 - 決定處理它。

    插入Pro_Table SELECT * FROM New_Rows_Table

    UPDATE Prod_Table 集Prod_Col_1 = Upd_tbl_c1, Prod_Col_2 = Upd_tbl_c2, ..., Prod_Col_N = Upd_tbl_cN 從Update_Table 其中Prod_Table.RowKey = Update_Table.RowKey

    DELETE FROM Prod_Table FROM Delete_Table 其中Prod_Table.RowKey = Delete_Table。RowKey

這是SQL Server代碼風格,但您可以獲取相關想法並進行必要的更改。例如,Delete_Table應該只有RowKey列。

如果不能創建一個唯一的密鑰。你有一些選擇:

號碼所有的行通過添加新柱,並用ROW_NUMBER填充它()函數。

OR

鎖定你的數據庫中的任何改變或不適用他們並單獨存放。在您的更改升級到Production後,應用已更改的更改。

OR

捕獲所有INSERT, '更新' 和Production數據庫使用觸發器DELETE語句。您需要插入,因爲它們可能會受到稍後的更新和刪除的影響。

當對Beta複製行進行更改時,您可以在Beta上手動更改爲單獨的表格。

完成更改後,請查看Production中的捕獲數據,並決定如何將它們應用於已更改並從Beta複製的行。

對於使用外鍵的avioid問題,請使用不同的名稱複製/導入更新的表。重命名原始表格,然後重新命名。放下原始表格。這樣您就不會刪除任何數據,並且所有外鍵都會一直執行。

+0

感謝您的回答,但它似乎仍然是一個複雜的解決方案...我正在尋找一些簡單的解決方案或信息,沒有這樣的:) – Wiktor

+0

你會如何定義「簡單」?你也可以從Access數據庫創建一個遠程連接,並直接編輯生產... – Stoleg

+0

「簡單」我的意思是解決方案,它的複雜性比按行手動處理要小10倍) – Wiktor

2

當我們保持生產數據庫我們通常做的是寫一個SQL腳本做更新,刪除,國家經貿委。我們用Beta來測試它,它應該是Production的一個不錯的副本。

當我們確定它做的是正確的事情時,我們會針對生產運行它。

我們不要將數據從非生產環境轉移到生產環境中。生產是數據的主人,並且獲取副本,執行更新,然後嘗試重新加載它是困難和可怕的(正如您已經想到的那樣)。

這種機制允許我們以確保測試腳本運行,這將使已知的更新投入生產。它消除了人爲錯誤,因爲當您連接到生產時,所有必須正確設置的都是腳本的名稱。

+0

我同意這是一個很好的做事方式,但我認爲這裏的情況有些不同,導致需要完成的更改必須由客戶端完成 - 我不能期望客戶端能夠編寫SQL腳本:) – Wiktor

+0

你應該馬上說它是**不是你**,誰會做出改變! – Stoleg

+0

是的,我們的情況通常也是這樣 - 在許多客戶中,我們無法獲得生產。我們根據我們有權訪問的測試系統中的數據編寫腳本,以及我們瞭解這些數據與生產數據的關係。然後,我們將腳本提供給客戶,並說「運行此」。有時需要關於如何運行腳本的說明,但它可以降低輸入錯誤的風險。 – GregHNZ

相關問題