希望你們中的一些人可能會遇到以下要求： - 我有基於桌面的產品，我們計劃將其用於雲計算。我們將只使用SQL-Azure中的一個數據庫併合並所有客戶的數據庫。對於合併，我們有以下選項： -在一個Cloud DB中合併多個客戶數據庫
* 。將NewCustomerID和現有的TableID作爲複合主鍵。
優點 - 易於導出數據庫，因爲它將很容易導出相關表，外鍵可用，因爲它在主表中。 - 推從雲回在內部部署db是容易實現
利弊 - 幾乎每一個表有複合主鍵和 - 有PERF的問題（谷歌搜索後的疑問，許多人認爲，謂複合鍵shud不導致性能問題）。首先EF代碼可能會導致一些問題。
* 。有了新的自動遞增的主鍵，並且仍然保持，NewCustomerID和舊TABLEID關鍵
利弊 - 表之間的關係將基於單個按鍵，易寫的查詢和EF代碼優先關係。
利弊 - 舊鑰匙
請提出您所選擇的一個額外的鍵和maintainence或者如果你對付這樣的場景在SQL Azure中
利弊喜歡完全新的方式 - 表之間的關係將基於單鍵和 易於編寫查詢和EF代碼的第一關係。
不正確或不完全正確。取決於「關係」的含義。見下文。
擁有單列自動遞增主鍵使許多事情變得更簡單，我可以推薦它。但是，在你的場景中，參照完整性約束仍然需要爲它創建替代組合（雙列）鍵，這些組合鍵將涉及約束。
爲清楚起見一個例子：
Customer A might not have "Azure" in their colors table
Customer B might have "Azure" in their colors table.
現在從兩個客戶的顏色表中的行已被合併成一個表：
COLORS
id integer primary key
customerid
colorname
因此，在一個假設的PRODUCTS表，你需要這個：
PRODUCTS
id integer primary key
customerid
colorid
alter table PRODUCTS add constraint
FK_PRODUCTS_COLORS
foreign key(colorid, customerid) references COLORS(id, customerid)
你不能簡單地這樣做：
alter table PRODUCTS add constraint
FK_PRODUCTS_COLORS
foreign key(colorid) references COLORS(id)
因爲這將允許客戶A使用「Azure」行。
這件不錯這是在SQL Azure中不斷增長的需求。但是我要指出的一件事是，將所有客戶數據庫整合到一個SQL Azure數據庫中並不一定是可擴展的設計。事實上，雲計算正在擴大規模，而不是擴大規模。因此設計一個有意擴大規模的數據庫是一個有點冒險的主張。請注意，SQL Azure具有內置的限制機制，可阻止長時間運行的查詢，過度使用資源等等;這種節流機制有助於防止擴大設計模式。
當涉及到設計對SQL Azure的數據庫，你基本上有以下幾種選擇：
鞏固在通過客戶ID單個數據庫的客戶記錄，然後計劃使用SQL Azure的數據聯合在以後的時間（注意：一些關鍵限制適用;該功能的可用性目前尚不清楚，但今年晚些時候會公佈某種公開聲明）。 Read into article from Cihan
使用可擴展性框架，例如Enzo Framework儘可能透明地創建分片（聲明：我是該技術的作者）。該技術允許您將客戶數據庫存儲在不同的數據庫，數據庫模式中，或者將這些數據庫混合在一起，並將來可以支持SQL Azure數據聯合。 Read my white paper on the topic
不需要擴展（所有客戶記錄適合單個數據庫實例，並且未來計劃可擴展）並且性能不會成爲問題，在這種情況下，您可以使用電子郵件中描述的方法（使用某些類型的客戶ID在邏輯上分開記錄）
彙總您自己的數據庫架構分離邏輯，其中每個數據庫架構包含不同客戶的表;使用一箇中心表，將客戶登錄指向正確的數據庫模式。 Read a high level description on MSDN here
Thanks Herve。你的鏈接和所有的點幫助我深入思考，你在回答中提到的第三個選項河 –
你提到的這個漏洞在技術上是可能的（雖然我們可以HV避免與我們允許客戶總是處理他數據的內部機制，但爲u提到，更好地對組合鍵參考鍵。但是有了第一個選項，我最終將PK作爲sqlAzure中數據庫的「EVERY」表的組合鍵，是否可以？ –
再次感謝Tim，您指引我朝着正確的方向發展。沒有別的選擇，只能在幾乎所有的sql azure數據庫中繼續使用複合主鍵（並且等待sql聯合服務） –