非營利性家庭援助的數據庫設計
我有一個非常基本的 ERD，它是為一個簡單的數據庫創建的，該數據庫儲存了一些關於由非營利組織幫助提供一些基本需求的難民家庭的資訊。
ID 是 Parent 的主鍵和 Children 的外鍵。
誠然，我是數據庫新手，所以我正在尋找有關如何改進此設計的提示。
我正在考慮的另一種方法：
Parent(parent_id, lastName, firstName, phone, notes) Home(Address, Street, Apartment, City, Zipcode) Stats(parent_id,DateOfArrival, DateReceived, CountryOfOrgin, Status) Children(parent_id, child_id, firstName, gender, age, shoe, notes)但我不確定在這種情況下連接表所需的主鍵和外鍵。查詢我是否可以正確連接似乎更容易。
一個範例查詢可能類似於“選擇所有具有相同街道名稱的孩子”（這將使運送物資更容易一些）。
謝謝你。
一項要求和幾點建議：
要求：您也應該有一個單獨的子記錄主鍵。也就是說，父記錄和子記錄都應該有名為“id”的欄位。然後，子記錄應該有一個名為“parent_id”的欄位。並且這個鍵應該有父級的 id 值。那有意義嗎？您可能已經進行了此設置，但我看不到您顯示的架構中的欄位。
我會考慮@JD 的建議，即為 CountryOfOrigin 設置一個單獨的表格。從技術上講，你可以為城市做同樣的事情。但是我要提出一個警告：這完全取決於您將如何查詢以及您對 SQL 的熟悉程度。是的，您的數據的完美規範化版本會從單獨的表中提取國家和城市，但這會增加（某些）查詢的複雜性，因為您必須加入這些表。同樣，許多人將整個地址放在單獨的表中，因為人們可以有多個地址（永久地址、郵寄地址、以前的地址等）。
就個人而言，我不是規範化純粹主義者。實際上，如果這個非營利組織的需求很簡單，並且他們/您在加入表格方面的經驗非常基礎，那麼就不要對數據進行規範化。但是，如果它們使您的事情變得更容易，請考慮所有這些可能的規範化。
例如，如果您的客戶可能想要儲存多個地址，那麼值得將其分離到另一個表中。如果他們不需要這種能力，那就不要這樣做。
同樣，如果您認為您需要為每個國家/地區儲存其他數據，或者按國家/地區查詢和過濾相當多的數據，那麼將其分離到自己的表中可能是有意義的（注意：您可以在主表中的一個國家/地區欄位，但這里分開到另一個表的原因是為了確保數據完整性。在您目前的設置中，沒有什麼能阻止一個人將美國、另一個美國和另一個美國記錄為國家。但是如果你有一個帶有國家名稱的表，並指向它，那麼數據庫將防止這種類型的數據不一致）。
因此，與往常一樣，它歸結為您的特定需求 :-) 但希望這些技巧能夠為您指明正確的道路。