0

我有一箇中央數據庫和一個獨特的數據庫爲我正在處理的項目。中央數據庫允許我爲用戶提供默認選項和數據。如何避免主鍵衝突時合併兩個相同的表與視圖

獨特的數據庫中心數據庫結構相匹配,讓用戶自己定製的數據。我認爲聯合每個相同的表對。

在每個視圖中的「主關鍵字」字段被設置爲在我使用(LINQ到SQL)dbml的主鍵。然後我將關聯添加到dbml中的其他表。

這意味着我不能將兩個表都設置爲自動遞增,其基數爲0,因爲主鍵在獨特的數據庫表中用作「外鍵」(我知道它們在此實例中不是嚴格的外鍵)。

因此,在本視圖中,我需要從每個表對所有記錄具有唯一的主鍵。

我曾經想過在1000000什麼設置獨特的數據庫PK基數,但當全球數據庫(0基地)趕上這最終可能會在我身上適得其反。

我也儘管在視圖中用數字前綴,例如,

全球:11,12,13,14,15,16,17,18,19,110,111 唯一:21,22,23,24,25,26,27,28,29,210, 211

我擔心如何查詢時,這可能會影響性能,這必須是儘可能高效。

不確定最佳方法?

+1

只要確保在每種情況下使用的數字範圍足夠大。一個INT的上限超過20億,如果這還不夠,你可以使用一個數據庫從零遞減的負數,另一個從零遞增的正數。如果仍然不夠,則使用BIGINT或NUMERIC。 – sqlvogel

+0

我喜歡這個消極的選擇,在這個例子中,我會繼續這樣做!乾杯! – Oliver

回答

0

你的解決方案的一個問題是它很脆弱,如果你需要兩個以上的來源合併,就會失敗。取決於您的業務場景,這可能是也可能不是現實的風險。

人們有時候會使用GUID的候選鍵解決這個問題。通過這種方式,您的源數據庫將IDENTITY列作爲PK,並且也是唯一但不是源數據庫中的主要GUID。然而,在合併的視圖中,PK是GUID,並且帶有原始源密鑰(IDENTITY),但實際上並未在PK/FK關係中使用。

在這種類型的模型中,合併視圖通常還包含某種源代碼列,告訴您該行來自哪裏。如果您這樣做,那麼源代碼+身份密鑰也是合併視圖中的候選鍵。

0

事實正好有另外的想法:

我可以設置獨特的底座1個增量2和全球基地2增量2.通過這種方式,沒有瘋狂的黑客和PK的永遠不會發生衝突