logo标签列表

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

c#.netoopdatabase-designdummy-data
3
在一些项目中，为了避免破坏数据库约束条件而不影响业务逻辑的进行，需要在数据库中创建虚拟记录。目前我见过两种使用方法：
- 添加一个名为IsDummy的字段。 - 添加一个名为ObjectType的字段，指向一个类型：Dummy。
这确实有助于实现目标。但是，这些虚拟记录存在于应用程序中，有时需要在某些流程中进行处理。否则，你会遇到一些问题，直到你意识到它们的存在或者直到团队中的某个人告诉你：“啊哈！你忘记了虚拟记录。你还应该...”
因此，问题是：是否创建虚拟记录以保持业务逻辑正常运行而不让数据库抱怨是一个好主意？如果是，如何最好地防止开发人员忽略它们的存在？如果不是，那么你要如何避免陷入只能创建虚拟记录的境地？
谢谢！
你能详细解释一下IsDummy和ObjectType的实际用途吗？为什么你的业务约束需要它们？ - Pieter van Ginkel
3
您永远不需要创建虚拟记录。我看不出虚拟记录有什么用途？如果您不使用虚拟记录，数据库会如何报错？您是在说一些选择语句使用此虚拟记录返回可添加的记录集吗？ - Scottie
2
凭借近15年的数据库开发经验，我认为我从未遇到过这种情况。这并不是说这种情况不可能出现，只是我认为这表明了设计上的错误。你能否给出更具体的例子，说明这个问题存在的地方和原因？ - Jamiec
我明白了。让我尽力用一个简单的案例来解释一下。假设你有一个Package对象，并且你已经实现了一个业务逻辑，即不能创建没有任何内容的Package。你创建了一些业务层规则，并设计了相关约束的数据库。但是几年后，需要一个新功能，为了实现这个功能，你必须能够创建一个没有内容的Package。为了解决这个问题，你决定创建一个虚拟内容，它在用户界面上不可见，但可以让你创建一个空的Package。我能再解释得更清楚一些吗？ - pencilCake
哈哈。我刚刚遍历了每一个反对使用所谓“虚拟对象”的回复（包括评论），并对它们进行了赞成——当时一共有10个这样的回复。 - user166390
8个回答
6

使用虚拟记录不如正确获取限制条件。

通常会有一种诱惑去使用虚拟记录，因为使用虚拟记录似乎是实现新功能最快的方式（也许有时确实是），但它们从来不是一个好的设计选择，因为它们隐藏了领域逻辑和数据模型之间的差异。

5
虚拟记录仅在建模者无法轻松更改数据库定义时才需要，这意味着定义和/或数据模型非常糟糕。我们永远不应该陷入这样的情况，即必须在应用程序层中使用特殊代码来处理数据库中的特殊情况。这将是一场维护噩梦。
任何良好的定义或模型都将允许轻松进行更改，而不会“影响现有代码”。
所有业务逻辑[定义在数据库中]都应使用ANSI SQL约束、检查和规则实现。(当然，较低级别的结构已通过域/数据类型等进行了约束，但我不会将它们归类为“业务规则”。)我通过做到这一点来确保我不必实现虚拟记录。
如果不能这样做，那么建模者缺乏知识和经验。或者高级要求（如规范化）已被打破，这就对实施依赖于它们的约束产生了障碍；这也意味着建模者失败了。
我从未需要打破这些约束或添加虚拟记录（我曾经在很多数据库上工作过）。我重新设计其他人创建的数据库时会删除虚拟记录（和重复记录）。
4

我从未遇到过需要这样做的情况。如果您需要这样做，那么您的数据结构可能存在问题，并且这将在后续报告中引起问题...

4

使用虚拟对象是愚蠢的。

通常情况下，您应该在不使用虚拟对象的情况下正确处理逻辑。我也见过它们被使用，但只作为一种紧急解决方案。您的描述听起来太像将其作为标准实践。这会带来更多问题而不是解决问题。

3

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

这绝对不是常规做法。

如果您的业务逻辑依赖于记录的存在，则需要执行以下两种操作之一：确保在执行该逻辑之前创建一个正确的记录；或者，更改逻辑以考虑缺少信息。

2
我认为任何情况下，如果某些内容不容易区分为“业务逻辑”，就应该尝试考虑更好的方法。
你提到“指向类型：Dummy”，让我相信你正在使用某种ORM来处理数据访问。像NHibernate这样的ORM解决方案非常好（虽然不是唯一的）之处在于，您的源代码非常明确地描述了驱动应用程序的数据结构。这不仅允许您的数据访问在源代码控制下轻松管理，而且还可以使以后出现问题时更容易调试（让我们面对现实吧，问题发生的问题不是“是否”，而是“何时”）。
当您引入某种“支架”（例如虚拟记录）时，您忽略了数据库的用途。数据库的存在是为了对您的数据执行规则，以消除此类需求。我建议您首先查看应用程序逻辑，然后再采用这种技术。考虑一下您的同事或新员工。如果他们需要添加功能并忘记了您的小“虚拟记录”逻辑，该怎么办？
您在问题中提到自己感到担忧。跟随直觉。摆脱虚拟记录。
2

我认为应该反对使用虚假记录(dummy records)。因为新开发人员可能不知道这些记录的存在，不会编写处理这些记录的代码，或者删除表时忘记添加虚假记录等问题可能会出现。

在遗留数据库中，我曾经见过上述情况的发生。

此外，虚假记录存在的时间越长，就越难以将其删除，并且需要编写更多的代码来考虑这些虚假记录，如果最初的设计没有使用虚假记录，那么这些记录可能本可以被删除。

2
正确的解决方案是更新您的业务逻辑。
引用您的详细说明： 假设您有一个Package对象，并且实现了一个业务逻辑，即不能创建没有任何内容的包。您创建了一些业务层规则并使用相关约束设计了您的Db。但是几年后，需要一个新功能来完成这个功能，您必须能够创建一个不带内容的包。为了克服这个问题，您决定创建一个虚拟的内容，它在UI上不可见，但可以让您创建一个空包。
因此，曾经一个没有内容的包是无效的，因此业务层强制要求包对象中存在内容。这是有道理的。现在，如果真实世界的情况发生了变化，因此现在需要创建没有内容的包，那么需要更改业务逻辑层。
几乎普遍地，在任何地方使用“虚拟”的任何东西都是一个坏主意，并且通常表示实现中存在问题。在这种情况下，您正在使用虚拟数据来允许与不再准确表示业务实际约束的业务层“合规”。
如果没有内容的包无效，则使用虚拟数据使业务层“合规”是一种愚蠢的黑客行为。本质上，您编写了保护自己系统的规则，然后如何绕过自己的保护。另一方面，如果没有内容的包是有效的，则业务层不应强制执行虚假限制。在任何情况下，虚拟数据都是无效的。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接