將學校名稱存儲在數據庫模式中

Question

我正在設計一個事件註冊系統的模式，該模式將涉及許多不同地區的學校的學生。我的主要問題是我將學校名稱存儲在數據庫中的方法。

鑑於學生將分開註冊，很可能隨着時間的推移，同一學校名稱的拼寫變化將會累積。我想要一個簡單的方法來清除這些，尤其是我們希望收集的統計數據之一是註冊該活動的學校和機構的數量。

我在一家Participant表中存儲school_name作爲一個額外的列，或存儲school_id作爲外鍵引用School表（想不出任何其他方式）之間的辯論。在存儲利用率，清除重複數據的難易程度以及其他因素方面，哪一個會更有效？

Answer 1

如果你想避免錯誤的可能性，你可以提供一個列表（是的，它可能很大）現有的學校名稱。如果他們選擇一個，則存儲該學校的ID。由於您可能無法預期所有學校，因此您可以爲「其他」學校設置自由格式的文本字段，並將其作爲文本存儲在參與者記錄中。您可能需要定期進行調節，以便將新的學校添加到學校名單中，或者將參與者的「其他」學校與現有學校相關聯（也許它在名單中，但他們只是沒有看到它或者可能拼錯了它）。

Answer 2

將ID作爲外鍵存儲到School表是更可取的，因爲它會減少重複。

Answer 3

「當它涉及到利用 存儲，便於清除重複數據 ，其他因素之一將被證明是更有效的 ？」

存儲很便宜，時間不是。因此，選擇一種方法可以最大限度地減少重複數據的時間，並通過提供預先準備好的學校列表來保存用戶的某些信息，並強制執行外鍵。

當然，這意味着你必須獲得這樣一個列表，並提供一個搜索機制，這比向用戶提供一個自由文本框無疑是更多的工作。沒有什麼是容易的:)但自由文本是標準化的敵人，所以儘可能避免它。根據你的個人資料，你位於新加坡。根據你的個人資料，你位於新加坡。如果這是您的應用程序所基於的地方，您可能會發現this Wikipedia page可以爲您節省大量的打字時間（有關維基百科適用的常見警告）。還有很多其他國家的學生名單。 Find out more。

---

「做‘自動完成’的字段作爲 靈活的替代下拉菜單？ '

他們可以做。但他們可能會完全惱人，特別是如果他們難以保證我們選擇了我們想要選擇的價值。我發現SO tag功能在這方面令人困惑，而我是一個技術類型。下拉菜單更易於理解。另一方面，大多數年輕人對預測性短信完全滿意，所以自動完成可能更適合他們。

Answer 4

學校名稱做隨時間變化。經歷過這樣的事情發生後，讓名字不是主鍵是很有意義的，也就是說，你有一個表格將他們映射到每個學校的ID，而這些學校從來沒有爲學校改變過。數據庫的其餘部分可以使用該ID，並且可以建立適當的外鍵關係;充分的kaboodle。你會想限制名稱列是唯一的;即使學校改名，也不會有兩個名稱相同，因爲它們在現實生活中以多個月的時間表運行，非常類似於PK（僅在多年的時間範圍內，您必須處理更改） 。