创建一个“虚拟记录”来强制数据库遵循业务逻辑，是一个好主意还是一个愚蠢的主意？答案

【问题标题】：Is creating a "dummy record" to force data-base obey the business logic, a good idea or a dumb one?创建一个“虚拟记录”来强制数据库遵循业务逻辑，是一个好主意还是一个愚蠢的主意？
【发布时间】：2011-05-08 00:10:19
【问题描述】：

在一些项目中，我发现需要在 Db 中创建一个虚拟记录，以便在不破坏 Db 约束的情况下保持业务逻辑继续运行。

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

通过添加像 IsDummy 这样的字段
通过添加一个名为 ObjectType 的字段，它指向一个类型：Dummy

好的，它有助于解决需要实现的目标。

但让我对此类解决方案感到警惕的是，有时您必须记住，应用程序中存在一些需要在某些进程中处理的虚拟记录。如果没有，您将面临一些问题，直到您意识到它们的存在或团队中的某个人告诉您“啊哈！您忘记了虚拟记录。您也应该这样做......”

所以问题是： 创建虚拟记录以保持业务逻辑不变而不让 Db 抱怨是个好主意吗？如果是，防止开发人员跳过他们的存在的最佳做法是什么？如果没有，您会采取什么措施来防止自己陷入最终只能选择创建虚拟记录的情况？

谢谢！

【问题讨论】：

您能否详细介绍一下 IsDummy 和 ObjectType 的实际用途？为什么您需要这些来解决您的业务限制？
您永远不需要创建虚拟记录。我看不到虚拟记录的用途是什么？如果您不使用虚拟记录，数据库会如何抱怨？你是说某些 select 语句使用这个 dummy 来返回可以添加的记录集？
拥有近 15 年的数据库开发经验，我想我从来没有遇到过这种情况。这并不是说它不可能，只是我认为这表明设计不正确。你能举一个更具体的例子说明这个问题在哪里/为什么存在。
我明白了。尽量用一个简单的案例来解释一下。假设您有一个 Package 对象，并且您已经实现了一个业务逻辑，即无法创建没有任何内容的 Package。您创建了一些业务层规则并设计了具有相关约束的数据库。但是几年后，需要一个新功能并且要实现它，您必须能够创建一个没有内容的包。为了克服这个问题，您决定创建一个在 UI 上不可见但允许您创建空包的虚拟内容。我能说得清楚一点吗？
哈哈。我刚刚浏览并投票每个响应（包括 cmets）反对使用所述“虚拟对象” - 当时它是全部 10 个。

标签： c# .net oop database-design dummy-data

【解决方案1】：

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

使用它们通常很容易，因为使用虚拟记录似乎是交付新功能的最快方式（有时可能是这样），但它们绝不是好的设计的一部分，因为它们隐藏了您的领域逻辑和数据模型之间的差异。

【讨论】：

【解决方案2】：

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

任何好的定义或模型都可以轻松地进行更改，而不会“影响现有代码”。

[在数据库中定义的]所有业务逻辑都应该使用 ANSI SQL 约束、检查和规则来实现。（当然，较低级别的结构已经受到域/数据类型等的限制，但我不会将它们归类为“业务规则”。）我确保我最终不必实现虚拟对象，只需这样做。

如果不能做到这一点，那么建模师缺乏知识和经验。或者更高级别的要求，如规范化，已经被打破，这给实施依赖于它们的约束带来了障碍；也意味着建模失败。

我从来不需要打破这样的约束，或者添加虚拟记录（而且我已经处理了很多数据库）。当我修改其他人创建的数据库时，我已经删除了虚拟记录（和重复）。

【讨论】：

【解决方案3】：

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

【讨论】：

【解决方案4】：

使用 Dummies 是愚蠢的。

一般来说，您的目标应该是在没有它们的情况下使您的逻辑正确。我也看到它们使用过，但仅作为紧急解决方案。您的描述听起来太像将其作为标准做法。这会导致比它解决的问题更多的问题。

【讨论】：

【解决方案5】：

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

这绝对不是常见的做法。

如果您的业务逻辑依赖于现有的记录，那么您需要做以下两件事之一：确保在执行该逻辑之前创建了正确的记录；或者，更改逻辑以考虑缺失的信息。

【讨论】：

【解决方案6】：

我认为任何不太容易区分为“业务逻辑”的情况都是尝试考虑更好方法的原因。

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

当您引入某种“拐杖”（例如虚拟记录）时，您忽略了数据库的意义。数据库可以对您的数据强制执行规则，以消除对此类事物的需求。我建议您在使用这种技术之前先查看您的应用程序逻辑。想想你的开发伙伴或新员工。如果他们需要添加一个功能而忘记了你的小“虚拟记录”逻辑怎么办？

您在问题中提到自己感到忧虑。跟着你的直觉走。摆脱虚拟记录。

【讨论】：

【解决方案7】：

我必须在这里遵循普遍的感觉并反对虚拟记录。

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

我在遗留数据库中体验过它们，并且看到了上述两种情况。

此外，它们存在的时间越长，取出它们就越困难，而且您必须编写更多的代码来考虑这些虚拟记录，如果您只是在没有它们的情况下进行原始设计，这些虚拟记录可能已经被删除。

【讨论】：

【解决方案8】：

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

引用您的扩展解释：

假设您有一个 Package 对象，并且您已经实现了一个业务逻辑，即无法创建没有任何内容的 Package。您创建了一些业务层规则并设计了具有相关约束的数据库。但是几年后，需要一个新功能并且要实现它，您必须能够创建一个没有内容的包。为了克服这个问题，您决定创建一个在 UI 上不可见但允许您创建空包的虚拟内容。

因此，一次没有内容的包是无效的，因此业务层强制在包对象中存在内容。这就说得通了。现在，如果现实世界的场景发生了变化，那么现在需要有效的理由来创建没有内容的包对象，那么需要更改的是业务逻辑层。

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

如果没有内容的包是无效的，那么允许“遵守”业务层的虚拟数据是一种愚蠢的黑客行为。本质上，您编写规则来保护您自己的系统，然后如何试图规避您自己的保护。另一方面，如果没有内容的包是有效的，那么业务层不应该强制执行虚假约束。在这两种情况下，虚拟数据都无效。

【讨论】：