更好的是，客戶數據庫還是統一數據庫？

如何使用Entity Framework來管理多個模式的單個C＃應用程序？或者應該只有一個模式？更好的是，客戶數據庫還是統一數據庫？

我有大約28的客戶，我不知道如果我保持每一個與單獨的數據庫或在一個單一的數據庫和統一管理我的信息的客戶ID爲例子。

我擔心數據量會阻礙應用程序的性能。我現在使用SQL Server 2014，每個版本都帶有一個系統版本，我們正在發展該系統並希望適合最佳方案。

我相信，通過客戶端訪問登錄控制的單個應用程序，更好地維護給予。

我不知道是否有可能有單獨的數據庫，因爲我有一些客戶誰喜歡有在他們的服務器自身架構的安全管理。

如何創建動態獲取連接字符串，請求的來源取決於上下文？

public class ProductRepository { 

public void Add(Product product, int clientId) 
{ 
    //Here the connection string will be set according to the client id you are saving information 
    var context = ContextFactory.GetContext(clientId); 
    context.Products.Add(product); 

} 

}

或者是否更好地放置在屬於該信息的實體客戶ID？

public class BaseEntity { 

    public int Id {get;set;} 
    public int Client_Id {get;set} 
} 


public class Products : BaseEntity{ 
    public string Name {get;set;} 
    public double Price {get;set;} 

}

來源

2016-07-03 Rafael Herik

你是否有經驗豐富的DBA誰將主持該應用程序？聽起來你對分佈式應用程序並不瞭解，特別是在住房/管理/支持多個客戶方面。花費這筆錢並付給專家它將長期爲您節省 – MethodMan

數據庫這個術語不幸有點含糊不清，我發現人們有時會用它來表示表，模式或整個服務器實例。你能澄清一下嗎？你想知道你是否應該把你的客戶放在同一張桌子上嗎？在相同的模式？或在同一個sql服務器實例？ –

抱歉，正確的術語是模式 –

每個方面都有優點和缺點，但我更願意爲每個客戶端分開數據庫實例。這爲可能需要的定製提供了更多的靈活性。

例如，如果你曾經對自己將要求您修改數據庫的架構工作的請求。如果每個客戶端都有一個數據庫，這不會是一大塊工作。如果你有一個單獨的數據庫和一個表來租用你的客戶端，那麼定製的改變會影響所有的客戶端，這可能會產生不必要的後果。

但是，由於擁有單獨的數據庫，您將增加可維護性的開銷。理想情況下，您應該爲每個客戶端（以及它們的版本）保留Schema生成的代碼遷移或SQL腳本，理想情況下，您將基線核心功能，而不是使用新表格更改數據庫中的核心表添加功能。在管理錯誤修復時，如果客戶端對數據庫模式進行了定製更改並且您正在使用新功能修補或僅修復已知錯誤，則這可能會變得非常複雜。

最後安全更容易管理與每個客戶端多個數據庫。每個數據庫都明確定義安全性。

如果你有1個數據庫，然後除非你在實現客戶端佃功能，那麼錯誤可能導致數據泄露挑剔。理想情況下，您希望確保您有足夠的單元測試來覆蓋任何租用的功能。在許多國家，數據泄露可以被嚴厲對待。例如在英國，對個人數據的數據泄露可能會使您獲得超過10萬英鎊的罰款。

總體而言，我認爲這將歸結爲個人偏好而不是最佳實踐。

來源

2016-07-03 22:20:41

實際上，相信定製並不是非常平常，每個人都會由同一個應用程序管理。從技術上講，我們評估了每種方式的優缺點，我希望即使在這種情況下也能達到最佳效果。 –

我不確定是否有最佳做法。微軟提供了許多可以在一個數據庫上進行租戶管理的應用程序。它的實施正確無誤。 –

更好的是，客戶數據庫還是統一數據庫？

回答

相關問題