本小菜在設計資料庫的時候，不幸遇到這樣乙個問題：
資料庫中有兩個表，分別是小組表和成員表。其中小組表中有乙個建立者字段，成員表中有乙個所屬組欄位。
看著挺符合邏輯的設計，卻引發了乙個哲學問題：先有雞先有蛋？兩個表形成了互相依賴。在資料庫剛剛建成的時候，兩個表中都沒有資料，那麼向任何乙個表中插入資料都是失敗的。
出現問題就要馬上解決，於是我便到網上搜尋，找到這樣一句話：「如果兩表互有關聯,則為多對多的關係,按照第三正規化規定,建立第三個中間表,用於儲存兩表主鍵,關聯時使用第三表的字段進行關聯.」。按照這個規則所說的，建立兩個中間表，用來儲存組表的主鍵和成員表的主鍵（另乙個表反之），然後用這兩個中間表進行關聯，這樣可以完美解決這個問題。
因為這兩個中間表解除了組表和成員表直接的相互依賴，轉化為了兩個中間表對組表和成員表的依賴。這樣看上去貌似不錯，可是仔細觀察一下會發現，在這個問題中並不是多對多的關係：乙個組只有乙個建立者，乙個成員只能屬於乙個組。
雖然可以用多對多的方法解決，但這並不是問題的根源。那麼問題出在**呢？試想一下，假如我們要建立乙個組，必須由人來建立，人的層次要高於組，而現在的設計人和組處於乙個對等的層次上，這樣顯然是不合理的。之所以這樣，是因為當初設計的時候，把所有的成員都放在乙個表中，不分普通使用者、操作員、管理員，這樣就導致降低了管理員的層次，從實際情況分析，管理員應該是不屬於某一組的。
所以，要真正解決這個問題，必須把具有管理功能的角色與普通角色分開，管理角色在組的層次之上，沒有所屬組，但是有建立組的許可權；而普通角色的層次在組之下，必須屬於某一組，沒有建立組的許可權。這樣就比較切合實際的解決了這個問題。需要說明的是，adminmember表和normalmember表只是代表許可權分級域表，並不表示成員型別，比如adminmember 表中可以放超級管理員、管理員、操作員等使用者型別，在normalmember表中可以有組員、組長、小組長等使用者型別，在memberall表中應該還有typeid欄位，來標識成員的型別。因此，在設計資料庫的時候，一定要分析表的層次結構，劃分出明確的域，避免出現互相依賴這樣的錯誤設計。
即便是這樣，個人感覺這個設計還不是很合理。可以看出，假如我們刪除了某乙個屬於adminmember表域的使用者，那麼這個使用者所建立的組也會由於外來鍵約束不得不刪除。這在實際應用中顯然是非常不合理的，這樣會導致系統混亂不堪。
因此，我認為雖然adminmember表和group表理論上有外來鍵約束關係，但是實際設計資料庫時不能加這個約束，我們只是為了記錄一下組的建立者，進而提供一些參考，並沒有嚴格的完整性要求，如果這個建立者不存在了，組應該還在。
先有雞還是先有蛋
有人認為 先有蛋，後有雞 雞是一種鳥類，凡是鳥類都是下蛋來繁殖後代 卵生。比鳥類低等的蛇 龜等爬行動物，圭蛙 蟾蜍等兩棲動物和形形色色的魚類都是卵生的。從生物的進化過程來看鳥類是由爬行動物進化而來的，在雞以前早已出現了比鳥類更低等的卵生物物，因此 先有蛋後有雞 雞的祖先，是一種生活在密林裡的野雞，叫...
先有雞還是先有蛋 資料庫中的相互依賴
本小菜在設計資料庫的時候，不幸遇到這樣乙個問題 資料庫中有兩個表，分別是小組表和成員表。其中小組表中有乙個建立者字段，成員表中有乙個所屬組欄位。看著挺符合邏輯的設計，卻引發了乙個哲學問題 先有雞先有蛋？兩個表形成了互相依賴。在資料庫剛剛建成的時候，兩個表中都沒有資料，那麼向任何乙個表中插入資料都是失...
先有雞還是先有蛋 資料庫中的相互依賴
本小菜在設計資料庫的時候，不幸遇到這樣乙個問題 資料庫中有兩個表，分別是小組表和成員表。其中小組表中有乙個建立者字段，成員表中有乙個所屬組欄位。看著挺符合邏輯的設計，卻引發了乙個哲學問題 先有雞先有蛋？兩個表形成了互相依賴。在資料庫剛剛建成的時候，兩個表中都沒有資料，那麼向任何乙個表中插入資料都是失...