比方说，我有一个帐户创建表单，填写用户数据库。假设这个数据库表有6列：UserID，UserLogin，Password，Email，Demographic1，Demographic2。实际需求与业务需求
程序确实需要UserID，UserLogin和Password。它不能没有。其余的是“业务需求”，公司想知道这些事情。他们是“必需的”。
构建我的应用程序和数据库以便实际需要这些应用程序和数据库，还是在业务逻辑中强制执行此约束会更好吗？
我的直觉告诉我第二个选择，但在我看到的几乎所有生产代码中，第一个通常就是这种情况。
这是缺乏计划，或某种形式的印记从业务/下午程序员（他们告诉我这是必需的，我会做到这一点）。或者，有没有令人信服的理由？
你应该这样做。限制数据库需要这个，如果必要的话会引发异常。这是如此，如果你曾经做过插入/更新这个规则将会在那里。
但是，在业务方面，这可以在表单上以可视方式表示，并作为验证逻辑弹出更好的错误消息。
去你认为最好的;你是程序员 - >一个拥有UserID，UserLogin和Password的数据库，并将其他数据库连接到该数据库。
事情是，就像生活中的许多事情一样，最后你会对你的选择负责，你可以通过做出比你的顾客更好的选择来区分你自己。顾客就像一个孩子，你是父母。你希望孩子开心，所以有时候你必须做出更好的选择，以便在更长的时间里更快乐。即使你的孩子（客户）和你的婆婆（老板）在另一个方向吸你...
我不知道我真的明白你的问题。如果您正在处理的域名将用户定义为实体，并且要求用户实体具有电子邮件，人口统计等，那么这些字段是必需的，并且应该在某种类型的永久存储（db，文件等）中持久化。
对我们的实际要求通常是指技术要求，这是程序真正需要的操作。我们通常在结构设计中强制执行它们，例如您的案例中的数据库约束。
业务需求处理业务感知的内容，以使应用程序可以接受。在大多数情况下，但不是全部，这通常涉及我们开发的计划如何产生投资回报。在我们的项目中，人口统计信息通常与某种营销活动相关联，后者可用于向用户推广某些内容或类似的内容。
我发现商务人士通常没有充分向我们解释业务需求的必要性，并简单地称他们为“必需”。只是说，如果我们不了解情况，就很难确定应该如何实施。如果我们知道业务需求是业务的核心，如果我们没有正确实施它，公司可能会损失很多，那么显然我们会选择一种更安全的方式来实现它。在你的情况下，这可能会通过将其嵌入结构约束本身。
为了回答您的问题，了解业务/业务需求的上下文和需求非常重要。既然你是在同一个团队中，你应该知道，为了做出最好的技术决定。作为一种个人信念，如果有疑问，我总是会进行更强的检查和验证（尽管这并不总是需要最好的决定）。
希望帮助
在某种程度上有意义。虽然，我认为“走最安全的路线”并不一定是最好的想法，但企业“需求”和“需求”有变化的趋势。在用户开始在创建帐户页面上开始保存之前，市场营销需要一个“人口统计”。然后突然“要求”改变。这样做会不会更好地以集中且易于更改的方式实施非技术要求？ – aepheus
投票决定一个深思熟虑的答案。 – aepheus
你有一个很好的营销示例:)我一直在那里。这就是为什么了解上下文很重要。如果您知道市场营销是模糊的，那么我们当然会采用您的方法来实施。在不知道重要性的情况下，我们很难做出正确的决定。我只想指出，需要在了解业务需求背景的基础上作出决定。最后一句更多地反映了我个人的立场，应该从答案中编辑。 – momo
通过将这些约束在数据库中，你问的数据库，以帮助执行业务逻辑。在数据库中执行这些约束有很好的理由。
问自己这个问题：你是否会删除外键约束？毕竟，它们只是业务限制。毕竟，您可以通过业务逻辑强制执行它们。
对我来说问题是要放入数据库的限制数量。作为一般规则，我在数据库中创建了两种类型的约束：外键和非空约束。这些都是速战速决，而且没有争议。关于代码重复的观点，你是对的，理论上你复制了一张支票，但是好处大于小问题。所以我把检查放在业务逻辑中，并且在数据库中添加一个非空约束。
您可以进一步了解不同类型的检查约束，但这通常不适用于我，因为现在您真的开始复制代码。
在数据库中实施外键和非空约束并不是一个完美的或完整的系统，但它确实发现了错误，它保护了您的数据，它可以帮助您完成工作。
是的，但是该存储（可以说DB）要求它们，还是应用程序的责任（应该是可以为空的） – aepheus
从我的角度来看，这取决于这些属性的生命周期（而不是空）。如果它们应该保留它们的值并且不以任何方式进行计算，那么将它们放入db。如果没有，让应用程序照顾他们。 – a1ex07
他们有一个无限的生命时间，我不想说他们不会被放在数据库中。我的问题是应该在数据库中执行“必需的”（但不是技术上要求的）约束，还是应该在业务逻辑中强制实施，还是两者都必须执行？ – aepheus