真实要求与业务要求

Question

假设我有一个帐户创建表单，它填充用户数据库。假设这个数据库表有6列：UserID，UserLogin，Password，Email，Demographic1，Demographic2。

该程序确实需要UserID，UserLogin和Password。没有它就无法运作。其余的是“业务要求”，公司想知道这些事情。他们是“必需的”。

构建我的应用程序和数据库是否更好，以便实际需要这些，或者在业务逻辑中强制执行此约束？

我的直觉告诉我第二个选择，但在我见过的几乎所有生产代码中，第一个通常就是这样。

这是缺乏规划，还是某种程序员对业务/下午的印记（他们告诉我这是必需的，我会让它成为必需）。或者，有一个令人信服的理由吗？

Answer 1

对我们的实际要求通常是指技术要求，这是该计划真正需要的操作。我们通常在结构设计中强制执行它们，例如在您的情况下作为DB约束。

业务需求涉及业务所感知的内容，以使应用程序可以接受。在大多数情况下，但不是全部，这通常涉及如何从我们开发的程序中生成ROI。在我们的项目中，人口统计信息通常与某种营销活动相关联，后来可用于向用户宣传内容的数据或类似内容。

我发现商业人士通常没有充分向我们解释业务要求的必要性，只是将其称为“必需”。只是声明在没有让我们理解上下文的情况下，我们很难确定应该如何实现它。如果我们知道业务需求是业务的核心，如果我们没有正确实现它，公司可能会损失很多，那么显然我们会选择更加安全的方式来实现它。在您的情况下，可能会将其嵌入结构约束本身。

为了回答您的问题，了解业务/ pm提出的业务需求的上下文和需求非常重要。既然你在同一个团队，你应该知道，以便做出最好的技术决定。作为个人信仰，如果有疑问，我总是会进行更强有力的检查和验证（尽管这不是必要的，总是会做出最好的决定）。

希望有所帮助

Answer 2

你应该两个都做。限制数据库要求这个，如果必然冒泡异常。这样，如果你做过sql插入/更新，那么这个规则就在那里。

但是，在业务方面，它在表单上以视觉方式表示，并作为验证逻辑弹出更好的错误消息。

Answer 3

去寻找你认为最好的东西;你是程序员 - ＆gt;一个包含UserID，UserLogin和Password的数据库，并将其他数据库连接到该数据库。

事实上，就像生活中的许多事情一样，最终你将对你的选择负责，你可以通过做出比顾客更好的选择来区分自己。顾客就像一个孩子，你就是父母。你希望孩子快乐，所以有时你必须为它做出选择，从长远来看它更有可能让它快乐。即使你的孩子（客户）和你的婆婆（老板）正朝着另一个方向吮吸你......

Answer 4

我不确定我真的理解你的问题。如果您正在处理的域将用户定义为实体，并且要求用户实体具有电子邮件，人口统计等，则这些字段是必需的，并且应该保留在某种类型的永久存储（db，file等）中。

Answer 5

通过将这些约束放在数据库中，您要求数据库帮助实施业务逻辑。在数据库中强制执行此类约束是有充分理由的。

1. 数据库是您的参考。它需要像正确一样 可能。在数据库中放置非空约束有助于此。 它强制执行一些业务规则，即使它不是前端 插入数据的结束GUI，例如来自a的批量插入 批处理或开发人员/ dba使用SQL更改数据以“修复”a 问题。
2. 它实际上帮助开发人员理解数据约束。挖掘代码以查明值是否为空有时有点困难，但查看数据库很容易。同样，如果您正在生成报告，并且您知道列不为空，那么它就会变得更容易。
3. 如果你知道一个值不应该为null，如果它为null则是一个错误，这允许快速失败的行为。如果任何人在没有通过业务逻辑或由于错误的情况下插入空值，那么将比在数据库中允许空值更快地找到错误。

问自己一个问题：你也会删除外键约束吗？毕竟，它们只是业务限制。毕竟，您可以通过业务逻辑强制执行它们。

对我来说，问题是要在数据库中放置多少约束。作为一般规则，我在数据库中创建两种类型的约束：外键而不是空约束。这些都是快速的胜利，而且毫无争议。关于代码重复的观点，你是对的，理论上你在复制支票，但好处超过任何小问题。所以我将检查放在业务逻辑中，并在数据库中添加一个非空约束。

你可以进一步研究不同类型的检查约束，但对我来说通常情况并非如此，因为现在你真的开始重复代码了。

在数据库中实施外键和非空约束并不是一个完美或完整的系统，但它确实可以找到错误，它可以保护您的数据，并且它可以帮助您完成工作。