這個數據庫結構是否理智，正確和規範化？

Question

因此，昨天我問了兩個圍繞着同樣想法的問題：重組一個數據庫，使A-沒有正常化，B-由於我的無知而變得混亂。我花了一整天的時間來組織我的想法，閱讀並通過一些測試。今天，我認爲我對DB的外觀和行爲有了更好的理解，但我想確保理解正確的SQL DB設計和規範化過程的核心思想。

本來我有一個名爲「文件」的表格，它包含關於文件的數據（它是URL，上傳日期，誰上傳它的用戶ID等）以及一個名爲「成績」可能會使用該文件。 （僅供參考：這些文件是學校的教案）我意識到我違反了關於規範化的規則＃1 - 我存儲了像「1,2」或「2,6」或「3,5,6」這樣的「等級」 「在一列中。如果我想看到JUST 3年級的課程或JUST 5年級的課程，這在試圖解析數據時造成了很大的麻煩。

什麼建議給我，後來又變成了什麼明顯的，是我有3個表：

文件（數據有關的文件，網址等） 等級（可用級水平的表可能的1 -6開始） files_grades（結表）

這是有道理的。我只是想確保我明白我在做什麼之前要做的事情。比方說，用戶A上傳文件xyz，並決定它對2和3年級是好的。

我會寫一個記錄到「文件」表與關於該文件的數據（大小，網址，描述，名稱，主key files_id）。比方說，它得到ID 345

由於等級選項數量有限，成績可能會被等同於他們的ID（即1級爲grades_id 1，2級是grades_id 2）

我會然後寫兩個記錄包含

files_grade_id，files_id的 「files_grade」 結表，grades_id即

1,345,2

1,345,3

表示files_id 345適合的2個等級。然後，我揮舞我的魔術SELECT和JOIN魔杖並拉出我需要的數據。

這是否有意義？我是否還誤解了關係型多對多數據庫的正確結構？

問題2剛剛在我身上恍然大悟：所以，一節課可以有多個「成績」。沒問題，我們只是解決了這個問題（我希望！）。但理論上它可以有多個「學校」 - 小學，中學，高等。如果一個文件條目的Middle，High等級爲1,2，我們該怎麼辦？通過說「每個文件一個學校，用戶！」可以很容易地解決這個問題，但我喜歡把它扔到那裏。

Answer 1

從它的聲音，它聽起來很不錯。但是，只有一件事：你並不需要爲橋接表（FILES_GRADES）設置一個ID，如果你這樣做，你需要增加ID。

您將有一個由兩部分組成的主鍵：grade_id和file_id，files_grade_id只是使事情複雜化，並且會導致錯誤的索引，因爲您從不在select中使用它。

Answer 2

然後我會寫兩個記錄包含

files_grade_id，files_id的 「files_grade」 結合表，並在這裏grades_id即

files_grade_id是多餘的，因爲組合files_id和grades_id已經唯一的（因而可以設置作爲主鍵）。

但理論上它可以有多個「學校」 - 小學，中學，高中。如果一個文件條目的Middle，High等級爲1,2，我們該怎麼辦？

根據您的要求，您可以將它們存儲爲以前成績的「延續」，例如， 1-6小學，7-9中間，10-12高。然後你就可以做無等級表完全（因爲你可以存儲在files_grade表這些數字）。

Answer 3

既然你第一個問題已經回答了，我會採取刺傷第二個。

有多種方法可以做到這一點，但一種可能性是添加另一個表的「學校」，並把它作爲聯接表的一部分 - 重命名過程的結合表以匹配新的設計。所以，你可以有：

School Table: 

------------------------- 
    SchoolId | School 
------------------------- 
    1  | Elementary 
    2  | Middle 
    3  | High 
------------------------- 

Files_grades_school 

------------------------------------ 
    FileId | GradeId | SchoolId 
------------------------------------ 
    345 |  1  |  1 
    345 |  1  |  2 

你可能會想要根據你的使用模式創建多個索引。