在使用多個數據庫的大型系統中。在數據庫中有多個表副本，以方便連接查詢或在程序中關聯數據？
如：用於貿易信息存儲
用於用戶帳戶存儲db_fund
db_trade使用
db_auth進行身份驗證和授權
在這種情況下user_info是常見信息。
貿易體系和基金制度 UI需要顯示貿易或帳戶，用戶信息的信息。爲了獲得更好的性能，它需要執行sql查詢left join user_info。
我wan't知道如何在更大的系統設計：
程序進行數據關聯？ 同步user_info在每個數據庫中的表？
有優點和缺點，每一種方法：
的歸一化的方法存儲的每個數據的恰好一次，並且是從數據完整性透視更好。這是關係數據庫設計中使用的傳統方法。例如，在銀行系統中，您可能不會將當前帳戶餘額保留在多個地方，對嗎？因爲當你在一個地方改變它時，另一個變得不一致，這可能導致錯誤的業務決策。
非規範化方法允許在不同位置存儲相同數據的多個副本，並且性能更好。這是通常建議用於大數據和NoSQL數據庫設計的方法。一個有意義的例子：假設你正在設計一個聊天系統，並且你需要在消息作者的名字旁邊顯示消息。您可能更願意將顯示名稱存儲在消息旁邊，而不僅僅是用戶標識，以便每次顯示消息時都不需要進行昂貴的加入。
如果反規範化，則需要在應用程序級別處理數據完整性。首先，你需要確保你清楚真相的來源。可以準備以低延遲獲取多個user_info副本，但應該有一個地方可以找到最正確和最新的用戶信息。這是用戶信息的主表。用戶信息的其他副本應該從中派生出來。因此，您必須決定設計中的哪一個數據庫是用戶信息的主數據。最後，你必須在一致性和性能之間進行權衡（這與可用性密切相關）。 如果user_info變化不大，而且您有很多查詢和大量用戶，並且性能是您主要關心的問題 - 請使用非規範化方法並在每個數據庫中同步user_info表。您的應用程序必須通過數據庫級別的複製或某些應用程序邏輯來保持這些表的一致性。
如果您在每個查詢（這不是典型情況）中都必須具有非常一致的user_info視圖，則可能需要犧牲性能並將所有用戶信息保留在一個位置。
一般來說，大數據系統犧牲一致性，有利於性能和可用性。