是否使用外鍵確實會有一些爭議。關於外鍵的使用：
首先，外鍵本身是為了實現強一致性，所以如果需要正確性>性能的話，還是建議使用外鍵，它可以讓我們在數據庫的層面保證數據的完整性和一致性。
當然不用外鍵，你也可以在業務層進行實現。不過，這樣做也同樣存在一定的風險，因為這樣，就會讓業務邏輯會與數據具備一定的耦合性。也就是業務邏輯和數據必須同時修改。而且在工作中，業務層可能會經常發生變化。
當然，很多互聯網的公司，尤其是超大型的數據應用場景，大量的插入，更新和刪除在外鍵的約束下會降低性能，同時數據庫在水平拆分和分庫的情況下，數據庫端也做不到執行外鍵約束。另外，在高並發的情況下，外鍵的存在也會造成額外的開銷。因為每次更新數據，都需要檢查另外一張表的數據，也容易造成死鎖。
所以在這種情況下，尤其是大型項目中后期，可以采用業務層來實現，取消外鍵提高效率。
不過在SQL學習之初，包括在系統最初設計的時候，還是建議你采用規范的數據庫設計，也就是采用外鍵來對數據表進行約束。因為這樣可以建立一個強一致性，可靠性高的數據庫結構，也不需要在業務層來實現過多的檢查。
當然在項目后期，業務量增大的情況下，你需要更多考慮到數據庫性能問題，可以取消外鍵的約束，轉移到業務層來實現。而且在大型互聯網項目中，考慮到分庫分表的情況，也會降低外鍵的使用。
不過在SQL學習，以及項目早期，還是建議你使用外鍵。在項目后期，你可以分析有哪些外鍵造成了過多的性能消耗。一般遵循2/8原則，會有20%的外鍵造成80%的資源效率，你可以只把這20%的外鍵進行開放，采用業務層邏輯來進行實現，當然你需要保證業務層的實現沒有錯誤。不同階段，考慮的問題不同。當用戶和業務量增大的時候，對於大型互聯網應用，也會通過減少外鍵的使用，來減低死鎖發生的概率，提高並發處理能力。