是否创建“虚拟记录”来强制数据基础遵守业务逻辑，一个好主意或愚蠢的逻辑？

Question

在某些项目中，我看到需要在DB中创建虚拟记录，以便保持业务逻辑继续而不会破坏DB约束。

到目前为止，我已经通过两种方式看到了它的用法：

• 通过添加像Isdummy这样的字段
• 通过添加一个名为Objecttype的字段，该字段指向一种类型：虚拟

好的，它有助于实现的目标。

但是，让我对这种解决方案感到警觉的原因是，您必须记住，应用程序中存在一些虚拟记录，需要在某些过程中处理。如果没有，直到您意识到它们的存在或团队中的某人告诉您“”，您才会面临一些问题。啊！您已经忘记了虚拟记录。你也应该做..."

所以问题是：创建虚拟记录以保持业务逻辑的情况下，这是一个好主意吗？如果是，防止开发人员跳过其存在的最佳实践是什么？如果没有，您该怎么做才能防止自己陷入最终创建虚拟记录的唯一选择？

谢谢！

Answer 1

使用虚拟记录不如正确的约束。

通常有一种诱惑来使用它们，因为使用虚拟记录似乎是提供新功能的最快方法（有时也许是），但是它们从来都不是 好的 设计，因为它们隐藏了您的域逻辑和数据模型之间的差异。

Answer 2

仅当建模器无法轻易更改数据库定义时，才需要虚拟记录，这意味着定义和/或数据模型非常糟糕。在应用程序层中必须有特殊代码来处理数据库中的特殊情况的情况下，绝不应该最终出现。那是一场保证的维护噩梦。

任何良好的定义或模型都将允许更改，而不会“影响现有代码”。

所有业务逻辑（在数据库中定义的）都应使用ANSI SQL约束，检查和规则来实现。 （当然，较低级别的结构已经通过域/数据型等受约束，但是我不会将它们归类为“业务规则”。）我确保我最终不需要实现假人，只是这样做。

如果不能这样做，那么建模器缺乏知识和经验。或更高级别的要求（例如归一化）已被打破，并且存在实施取决于它们的限制的障碍；这也意味着建模器失败。

我永远不需要打破此类约束，也不需要添加虚拟记录（我已经在很多数据库中工作了）。当我重新设计由他人创建的数据库时，我已删除了虚拟记录（和重复）。

Answer 3

我从来没有遇到过这样做。如果您需要这样做，那么您的数据结构有问题，这将导致报告进一步报告...

Answer 4

使用假人是愚蠢的。

通常，您应该在没有它们的情况下将逻辑正确。我也看到它们也使用了，但仅作为紧急解决方案。您的描述听起来太像使其成为标准练习。这将导致比解决方案更多的问题。

Answer 5

我可以看到添加“虚拟”记录的唯一原因是当您拥有严重的应用程序和数据库设计时。

绝对不是常见的做法。

如果您的业务逻辑取决于存在的记录，则需要做两件事之一：要么确保在执行该逻辑之前创建正确的记录；或者，更改逻辑以考虑丢失的信息。

Answer 6

我认为，任何情况都不容易区分为“商业逻辑”的任何情况都是试图思考更好方法的原因。

您提到的“指点：虚拟”的事实使我相信您正在使用某种ORM来处理数据访问。诸如NHibernate之类的ORM解决方案的一个非常好的检查点（尽管不是唯一的）是，您的源代码非常明确地描述了驱动应用程序的数据结构。这不仅允许您的数据访问在源控制下轻松管理，而且还允许在出现问题的情况下更轻松地调试线路（让我们面对现实吧，这不是问题是否会出现，而是何时出现问题）。

当您像虚拟记录一样引入某种“拐杖”时，您会忽略数据库的点。有一个数据库来对您的数据执行规则，以消除对这种事情的需求。我建议您先看看您的应用程序逻辑，然后再诉诸于这种技术。考虑一下您的Dev同伴或新员工。如果他们需要添加功能并忘记您的小“虚拟记录”逻辑怎么办？

您在问题中提到自己的忧虑。和你的肠子一起去。摆脱虚拟记录。

Answer 7

我必须在这里采取共同的感觉，并反对虚拟记录。

将会发生的是，新的开发人员不会知道它们，也不会代码来处理它们，或删除表，而忘记添加了新的虚拟记录。

我在旧数据库中经历了它们，并看到上述这两个发生的事情。

同样，它们存在的时间越长，将它们取出的难度就越难，并且您必须编写的代码越多地考虑到这些虚拟记录，如果您只是在没有它们的情况下进行了原始设计，可能会被删除。

Answer 8

正确的解决方案是更新您的业务逻辑。

引用您扩展的解释：

假设您有一个软件包对象，并且已经实现了无法创建任何内容的软件包的业务逻辑。您创建了一些业务层规则，并通过相关约束设计了数据库。但是几年后，请求新功能，并完成您必须能够创建一个无偶然性的软件包。为了克服这一点，您决定创建一个虚拟内容，该内容在UI上不可见，但可以创建一个空软件包。

因此，一次无效的软件包的包裹是无效的，因此在软件包对象中强制存在内容的业务层。这就说得通了。现在，如果现实世界的方案发生了变化，现在需要有效的理由创建包装对象而没有内容，则需要更改业务逻辑层。

几乎普遍使用“虚拟”任何地方的任何东西都是一个坏主意，通常表明实施中存在问题。在这种情况下，您正在使用虚拟数据来允许“合规”与不再准确代表业务的现实限制的业务层。

如果没有内容的软件包无效，则虚拟数据允许“合规”与业务层“合规”是一个愚蠢的黑客。从本质上讲，您编写了保护自己的系统的规则，然后如何试图规避自己的保护。另一方面，如果没有内容的包装有效，则业务层不应执行伪造的约束。在这两个实例中，虚拟数据都是有效的。