嵌套表層次結構：外鍵複製與連接

我有一個嵌套表層次結構，類似於以下層次結構（這是一個範例，但很好地展示了架構）：

+---------+  +---------+  +---------+  +-------------+
| users   |  | blogs   |  | posts   |  | comments    |
+---------+  +---------+  +---------+  +-------------+
| user_id |  | blog_id |  | post_id |  | comment_id  |
| email   |  | user_id |  | blog_id |  | post_id     |
+---------+  | name    |  | content |  | comment     |
            +---------+  +---------+  +-------------+

因此，對象層次結構清晰：一條評論屬於單個文章，屬於單個部落格，屬於單個使用者。

現在，在我的應用程式碼中，我想驗證評論只能由擁有文章的部落格的使用者閱讀（假設這些是私人評論，好嗎？）。例如，當 I 時SELECT * FROM comments WHERE comment_id = 666，我想驗證請求使用者“擁有”該評論。

我的困境是：你會建議我：

• 複製user_idto comments，所以我總是可以快速參考擁有使用者，並且檢查使用者 ID（在選擇期間或以後）很簡單，或者
• 編寫我的數據庫訪問程式碼（映射器或你有什麼）以始終加入並獲取 user_id 欄位作為返回對象的一部分。請注意，在這種情況下，我需要兩個 JOIN 才能做到這一點

基本上，我將其視為性能與所謂的數據複製不良做法的對比——但在這種情況下，這真的是一種糟糕的做法嗎？值不太可能user_id改變或 ablog改變它的user_id.

如果這有什麼不同，我正在使用 MySQL（實際上是 MariaDB）。

您顯然應該選擇第二種選擇，原因有很多：

• 如果您需要提出具有相同評論級別的實體，您會再次添加使用者 ID 嗎？可能它不會在您的場景中發生，但仍然會發生。
• 儲存，隨著數據庫大小的增長
• 不會對性能產生太大影響，因為您的查詢具有高度選擇性，並且如果您有良好的索引設計。

在我看來，您應該採用第二種方式，即 INNER JOIN。因為，在我的理解中，這不會是對數據庫的關鍵查詢（閱讀密集型），這種方法將是最好的，為了簡化開發並實現“良好實踐”。除此之外，評論可能很多，並且保留一個額外的使用者 ID 會一次向您的數據庫添加幾個字節。

引用自：https://dba.stackexchange.com/questions/115587