錶鏈，什麼時候反規範化？

Question

說TABLE-A可以在TABLE-B中有一個或多個行，TABLE-C中可以有一個或多個行，TABLE-D中可以有一行或多行，等等。

說我在TABLE-Z並需要知道TABLE-A的細節。我是否可以創建一個從TABLE-Z一直到TABLE-A的SQL查詢？在某些時候，如果TABLE-Z對TABLE-A有一個FK，這樣查詢不會那麼痛苦，那麼也許會很好。但是，如果我把這個FK，我想我會打破正常化，對吧？

關於如何處理這個問題的一般建議？

Answer 1

如果您使用複合主鍵（如果您在創建任何表之前正確地對設計進行建模，那麼實際上會發生這種情況），TableA中的鍵已經包含在TableZ中（作爲最左邊的列）。

但是，民間人士通常在不理解的情況下添加代理鍵爲什麼。因此，您需要加入所有26個表以建立TableA和TableZ之間的鏈接。TableA和TableZ之間的額外FK可能與某些中間外鍵衝突;這就是爲什麼非規範化（或非標準化）數據存在固有風險並應慎重使用。

但是，你通常不會有26級嵌套表。使用2,3或6個主鍵意味着我可以將TableA連接到TableF而不需要任何中間表。

就個人而言，我會使用複合鍵，並避免額外的FK，除非我有一個已知的，可重現的和可證明的瓶頸。大多數數據庫不會注意到任何區別..所以還沒有優化

Answer 2

在某些情況下，如果查詢的時間/內存使用比保持表的規範化更重要，則可以對錶進行非規範化。假設你選擇了幾千行，從表Z到A的整個過程都需要很長時間。

基本上我會說這取決於你。如果保持表格標準化非常重要，請不要將它們標準化。如果查詢的速度和內存使用更重要，則應該對錶格進行非規範化處理。

希望有幫助！