比方說，我有一個帳戶創建表單，填寫用戶數據庫。假設這個數據庫表有6列：UserID，UserLogin，Password，Email，Demographic1，Demographic2。實際需求與業務需求
程序確實需要UserID，UserLogin和Password。它不能沒有。其餘的是「業務需求」，公司想知道這些事情。他們是「必需的」。
構建我的應用程序和數據庫以便實際需要這些應用程序和數據庫，還是在業務邏輯中強制執行此約束會更好嗎？
我的直覺告訴我第二個選擇，但在我看到的幾乎所有生產代碼中，第一個通常就是這種情況。
這是缺乏計劃，或某種形式的印記從業務/下午程序員（他們告訴我這是必需的，我會做到這一點）。或者，有沒有令人信服的理由？
你應該這樣做。限制數據庫需要這個，如果必要的話會引發異常。這是如此，如果你曾經做過插入/更新這個規則將會在那裏。
但是，在業務方面，這可以在表單上以可視方式表示，並作爲驗證邏輯彈出更好的錯誤消息。
去你認爲最好的;你是程序員 - >一個擁有UserID，UserLogin和Password的數據庫，並將其他數據庫連接到該數據庫。
事情是，就像生活中的許多事情一樣，最後你會對你的選擇負責，你可以通過做出比你的顧客更好的選擇來區分你自己。顧客就像一個孩子，你是父母。你希望孩子開心，所以有時候你必須做出更好的選擇，以便在更長的時間裏更快樂。即使你的孩子（客戶）和你的婆婆（老闆）在另一個方向吸你...
我不知道我真的明白你的問題。如果您正在處理的域名將用戶定義爲實體，並且要求用戶實體具有電子郵件，人口統計等，那麼這些字段是必需的，並且應該在某種類型的永久存儲（db，文件等）中持久化。
對我們的實際要求通常是指技術要求，這是程序真正需要的操作。我們通常在結構設計中強制執行它們，例如您的案例中的數據庫約束。
業務需求處理業務感知的內容，以使應用程序可以接受。在大多數情況下，但不是全部，這通常涉及我們開發的計劃如何產生投資回報。在我們的項目中，人口統計信息通常與某種營銷活動相關聯，後者可用於向用戶推廣某些內容或類似的內容。
我發現商務人士通常沒有充分向我們解釋業務需求的必要性，並簡單地稱他們爲「必需」。只是說，如果我們不瞭解情況，就很難確定應該如何實施。如果我們知道業務需求是業務的核心，如果我們沒有正確實施它，公司可能會損失很多，那麼顯然我們會選擇一種更安全的方式來實現它。在你的情況下，這可能會通過將其嵌入結構約束本身。
爲了回答您的問題，瞭解業務/業務需求的上下文和需求非常重要。既然你是在同一個團隊中，你應該知道，爲了做出最好的技術決定。作爲一種個人信念，如果有疑問，我總是會進行更強的檢查和驗證（儘管這並不總是需要最好的決定）。
希望幫助
在某種程度上有意義。雖然，我認爲「走最安全的路線」並不一定是最好的想法，但企業「需求」和「需求」有變化的趨勢。在用戶開始在創建帳戶頁面上開始保存之前，市場營銷需要一個「人口統計」。然後突然「要求」改變。這樣做會不會更好地以集中且易於更改的方式實施非技術要求？ – aepheus
投票決定一個深思熟慮的答案。 – aepheus
你有一個很好的營銷示例:)我一直在那裏。這就是爲什麼瞭解上下文很重要。如果您知道市場營銷是模糊的，那麼我們當然會採用您的方法來實施。在不知道重要性的情況下，我們很難做出正確的決定。我只想指出，需要在瞭解業務需求背景的基礎上作出決定。最後一句更多地反映了我個人的立場，應該從答案中編輯。 – momo
通過將這些約束在數據庫中，你問的數據庫，以幫助執行業務邏輯。在數據庫中執行這些約束有很好的理由。
問自己這個問題：你是否會刪除外鍵約束？畢竟，它們只是業務限制。畢竟，您可以通過業務邏輯強制執行它們。
對我來說問題是要放入數據庫的限制數量。作爲一般規則，我在數據庫中創建了兩種類型的約束：外鍵和非空約束。這些都是速戰速決，而且沒有爭議。關於代碼重複的觀點，你是對的，理論上你複製了一張支票，但是好處大於小問題。所以我把檢查放在業務邏輯中，並且在數據庫中添加一個非空約束。
您可以進一步瞭解不同類型的檢查約束，但這通常不適用於我，因爲現在您真的開始複製代碼。
在數據庫中實施外鍵和非空約束並不是一個完美的或完整的系統，但它確實發現了錯誤，它保護了您的數據，它可以幫助您完成工作。
是的，但是該存儲（可以說DB）要求它們，還是應用程序的責任（應該是可以爲空的） – aepheus
從我的角度來看，這取決於這些屬性的生命週期（而不是空）。如果它們應該保留它們的值並且不以任何方式進行計算，那麼將它們放入db。如果沒有，讓應用程序照顧他們。 – a1ex07
他們有一個無限的生命時間，我不想說他們不會被放在數據庫中。我的問題是應該在數據庫中執行「必需的」（但不是技術上要求的）約束，還是應該在業務邏輯中強制實施，還是兩者都必須執行？ – aepheus