我在過去的經歷中看到，大多數人不會在表格中使用物理關係，他們會嘗試記住它們並僅通過編碼來應用它們。數據庫設計：藝術或頭痛（管理關係）
這裏物理關係「是指主鍵，外鍵，檢查約束等
在設計數據庫的時候，人們嘗試正常化紙面上的數據庫，並讓事情記錄。就像，如果我必須爲營銷公司創建一個數據庫，我會嘗試瞭解它的要求。 例如，什麼字段是強制性的，哪些字段只包含（a或b或c）等。
當所有的事情都清楚的時候，爲什麼大多數人都害怕約束？
您認爲什麼原因？
嗯，我的意思是，每個人都有權自己的意見和發展戰略，我想，但在我的愚見，這些人幾乎肯定是錯了:)
的原因，但是，有人可能希望避免限制是效率。不是因爲約束很慢，而是因爲存儲冗餘數據（即緩存）是加速（很好，避免）昂貴計算的非常有效的方式。這是一個可接受的方法，如果正確實施（即緩存更新爲定期/適當的時間間隔，通常我會通過觸發器執行此操作）。
至於沒有緩存動機的動機不是我們FKs，我無法想象它。也許他們的目標是在他們的數據庫結構中「靈活」。如果是這樣，很好，但不要使用關係型數據庫，因爲它毫無意義。非關係數據庫（OO dbs）當然有它們的位置，甚至可能會更好（可爭論的，但有趣的爭論），但使用關係數據庫並不使用它的核心屬性是一個錯誤。
這是否意味着在數據庫上應用限制會使他們難以管理，並且如果管理不當，可能會產生很大的問題。 – 2010-07-22 05:32:08
@ Shantanu：不，這並不意味着。事實並非如此（事實上，情況正好相反）。 – 2010-07-22 05:56:14
我總是有DBMS強制執行主鍵和外鍵約束;我也經常添加檢查限制。就我而言，數據太重要了，不會存儲不準確數據的風險。
如果您將數據庫視爲一系列存儲的真正邏輯命題，您會看到如果數據庫包含錯誤命題 - 錯誤 - 那麼您可以根據需要進行任何結論。給定一個錯誤的前提，任何結論都是正確的。
爲什麼其他人不使用PK和FK約束等？有些人不瞭解他們的重要性（所以缺乏知識絕對是一個因素，甚至是一個主要因素）。其他人則害怕他們的性能會花費太多，忘記了一個必須解決的錯誤可能很容易耗盡所有的時間，因爲沒有DBMS爲您檢查。我認爲，如果當前的DBMS不能很好地處理它們，那麼可能（可能是）更改DBMS。
如果我將42存儲到一個名爲Answer的字段中，我不知道是否應該對它進行約束，因爲它可能需要750萬年... – 2010-07-22 06:51:03
有在重要性依次遞減沒有強制關係，有幾個原因：
人民友好的錯誤處理。 您的程序應檢查約束條件並向用戶發送可理解的消息。由於某些原因，普通人不喜歡「SQL異常代碼-100013違反gook規則」。
操作靈活性 您不希望您的操作員試圖弄清楚您必須在3凌晨，你也不希望你的測試人員拉了頭髮因爲他們不能將數據庫恢復到起始位置。
效率。 Cheking約束不佔用IO和CPU。
功能。 其一個便宜的方式來保存細節以備後用非常。例如，在線上訂單系統中，當用戶殺死父母訂單時，如果他稍後恢復訂單，細節就會重新出現，就像奇蹟一樣，您可以在表格中留下明細項目行 - 您可以通過以下方式獲得這一額外功能：刪除代碼行。 （當然你需要一些家務過程，但它是微不足道的！）
如果您更改了第一個問題，我會放棄您的回答而不是降低投票回報率從沒有強制約束的「原因」判斷爲不使用它們的「藉口」。 – ObiWanKenobi 2010-07-22 11:16:59
ObiWanKenobi +1，詹姆斯安德森-1。將孤行視爲一項功能並將其清理爲「微不足道」的內務管理流程需要一種罕見的觀點。 – 2010-07-22 12:17:55
我會一直定義PK和FK約束。特別是在使用ORM時。它確實讓每個人都可以輕鬆地讓ORM對數據庫進行反向工程，而不是手動配置它來使用一些PK和FK。
許多開發人員會在他們真正執行操作之前檢查數據庫上方代碼中的約束。有時，這是由用戶體驗考慮（我們不想向無法保存到數據庫的用戶提供選擇/選項）驅動的。在其他情況下，它可能是由執行一個陳述，確定其失敗原因，然後採取糾正措施相關的痛苦所驅動的。大多數人會認爲，如果代碼事先進行了檢查，以及可能起作用的其他業務邏輯，代碼更易於維護，而不是通過異常處理程序採取糾正措施。 （這不一定是理想的思路，但它是一種普遍的思路）。無論如何，如果您在發佈聲明之前進行檢查，並且不特別意識到數據庫可能會被觸及的事實由沒有通過完整性執行代碼進入的應用程序/用戶，那麼您可能會得出結論：數據庫約束是不必要的，特別是在使用數據庫時可能會導致性能下降。另外，如果您在數據庫上方的應用程序代碼中檢查完整性，則可能會認爲它違反DRY（不要重複自己）以在數據庫本身中執行邏輯上等效的檢查。如果不仔細管理，完整性規則的兩種表現（數據庫約束和數據庫上方應用程序代碼中的那些）原則上可能會不同步。
此外，我不會打折選項2，許多開發人員對數據庫限制太不瞭解。
我必須同意，devlopers傾向於考慮他們的應用程序是否需要這一點，而不是根據其他應用程序或進程是否也可能觸及數據庫。完整性檢查屬於數據庫。如果有人想在插入之前檢查它們，那對我來說沒問題，但它們屬於數據庫中的首要和前兆。您必須在所有數據插入/更新發生的唯一位置 - 數據庫中保護數據的完整性。 – HLGEM 2010-07-22 18:36:40
隨着事情變得越來越複雜，數據庫中需要更多的表和關係，如何確保數據庫開發人員記得檢查所有這些表？當您對添加新的「非正式」關係的模式進行更改時，如何確保所有可能受到影響的應用程序代碼都得到更改？
突然之間，您可能會刪除應保留的記錄，因爲他們有相關數據，開發人員在寫入刪除過程時忘記檢查相關數據，或者因爲該過程在最後十個相關表添加到模式之前已到位。
不正式地建立PK/FK關係是極端愚蠢的。我處理從許多不同供應商和數據庫收到的數據。您可以確定哪些數據完整性問題很可能是由於未能通過數據質量差來明確定義關係而導致的。
我想有些團隊首先創建數據模式，然後爲其創建一個或多個用戶界面;有些人會先創建應用程序，然後修改他們的數據庫，因爲需要存儲信息...... – pascal 2010-07-22 06:29:51