資料庫建表時一定要設置外鍵約束關係嗎？

01-13

我們都知道每張數據表都有一個能夠確定每行數據唯一性的欄位，也就是主鍵。而在關係資料庫中，常常有兩表存在一定關係的情況。即一張表的主鍵跟另一張的外鍵存在對應關係，我們知道這種關係是存在的，那麼我們在創建資料庫表的時候是否一定要把外鍵關係約束加上呢？因為一旦創建了這個關係，在開發中就可能遇到莫名其妙的問題，所以我一般都是不設置外鍵關係，只設置主鍵約束。而兩表的主外鍵關係在實際開發中通過程序來控制，達到數據的完整性，一致性。曾經在面試的時候遇到這樣的問題，面試官反駁我的做法，但是我沒有明白不設置主外鍵的關係與設置主外鍵關係的利害關係以及是否會設計到資料庫的性能問題。誰能來講解一下呢？

外鍵的存在是有意義的，例如一個人的基本信息和工資分別存放一張表。

如果有一天，你發現一個找不到基本信息的人，卻有工資信息，問題就出現了。

我最近也有碰到這個問題，我使用的是一個基於postgresql的分散式資料庫，postgresql支持外鍵約束，分散式資料庫不支持外鍵，讓我很迷惑，我想通過powerdesigner來逆嚮導出資料庫一些表的ER關係，發現沒有約束的時候這樣做很糟糕，只能導出基本的表結構，完全要手動操作。

感覺在一些大數據應用的系統一般不考慮外鍵約束可以提高性能，小型系統了、業務邏輯很強但是數據量不是很大的資料庫一般會使用外鍵約束

想跟大家討論，資料庫建表需要外鍵約束嗎？

Instrumentation and the cost of Foreign Keys

外鍵約束畢竟是一個約束，只是保證數據完整性的一個手段。

資料庫系統本身約束手段是更可靠的。

對於開發來說，可能覺得建立外鍵關係沒必要，但是到了以後維護階段，或升級階段，如果沒有這個關係，可能不利維護工作的提升。表關係的建立，也闡述著具體的業務邏輯關係，增加了可讀性。

在邏輯性，關聯性比較強的時候不妨添加。

其他時候簡單的外鍵約束也是可以的，不需要一有關係就添加，但是要有其他機制保證數據完整性，畢竟外鍵對於開發有時候還是有限制。

總的來說前期開發可以不管，後期維護盡量轉移到資料庫本身的約束來建立關係。

SQL的主鍵和外鍵約束 - chenlaoyang的專欄 - 博客頻道 - CSDN.NET---這是一個大神的博客, 你需要的基本都在這裡.

實際上對於性能要求較高的項目是單表設計的,不設置外鍵,外鍵的根本目的是關聯,以及保持兩個表這個欄位值相同,

實現這個目標自然可以通過外鍵約束(就是用來約束這個的)來實現,如果嘗試用代碼來手動的維護這個約束是否可行.

資料庫無非是增刪改查, 也就只需要確保在增,刪,改的時候,如果修改第一個表中這個欄位,那麼第二個表也要做相應的處理的,並且確定這兩個操作要麼都成功要麼都失敗, 也就是增刪改的時候,兩份操作,放在一個事務中

我接觸的信息系統，在建立數據表的時候，的確不建立外鍵約束。實際操作過程中，通過應用程序或觸發器建立約束關係。這樣在維護數據過程中比較方便

你的想法大體上是沒有問題的，並且我在實際項目開發過程中也是這樣做的，但你回答的沒有做到滴水不漏，假如在你的回答後面再加上一句話就完美了。

所以我一般都是不設置外鍵關係，只設置主鍵約束，而兩表的主外鍵關係在實際開發中通過程序來控制，達到數據的完整性，一致性。當然了，具體的操作還需根據實際項目的架構來安排，對我本人來說這兩種做法都無技術層面的問題。

這是一個平衡開發成本與維護成本的問題。

尤其是當你的產品是由客戶開發的，而客戶又有能力自行做Customisation的時候，一個外鍵約束是對數據完整性的又一重保證。

當然，如果資料庫在Release後能做好封裝，前端又可以有效保證數據的完整的話，答案可以是No

外鍵的作用到底是什麼？

目前實習接觸的項目（題庫），資料庫里完全沒有外鍵的約束，我想這樣是為了在刪除過程中不會報錯吧。

-------------------------------------------------------------------------------------------

此外也方便以後對資料庫進行分庫和分表。

冗餘設計可以提高查詢的性能。