正在创建“虚拟记录”强制数据库服从业务逻辑，是好主意还是愚蠢的主意？
在某些项目中，我发现需要在数据库中创建虚拟记录，以便在不破坏数据库约束的情况下保持业务逻辑继续进行。
到目前为止，我已经通过两种方式看到了它的用法：
- 通过添加像 IsDummy 这样的字段
- 通过添加一个名为 ObjectType 的字段，它指向一个类型：Dummy
好吧，它有助于实现需要实现的目标。
但让我对此类解决方案感到警惕的是，有时您必须记住应用程序中存在一些虚拟记录，需要在某些进程中进行处理。如果没有，您将面临一些问题，直到您意识到它们的存在或直到团队中有人告诉您“啊哈！您忘记了虚拟记录。您也应该这样做......”
所以问题是： 创建虚拟记录以保持业务逻辑不变而不引起数据库抱怨是一个好主意吗？如果是，防止开发人员跳过它们的存在的最佳实践是什么？如果没有，您如何防止自己落入只有创建虚拟记录的唯一选择的境地？
谢谢！
In some projects I see that a dummy record is needed to create in Db in order to keep the business logic go on without breaking the Db constraints.
So far I have seen its usage in 2 ways:
- By adding a field like IsDummy
- By adding a field something called ObjectType which points a type: Dummy
Ok, it helps on what needs to be achieved.
But what makes me feel alert on such solutions is sometimes you have to keep in mind that some dummy records exist in the application which needs to be handled in some processes. If not, you face some problems until you realize their existence or until someone in the team tells you "Aha! You have forgotten the dummy records. You should also do..."
So the question is:
Is it a good idea to create dummy records to keep business logic as it is without making the Db complain? If yes, what is the best practice to prevent developers from skipping their existence? If not, what do you do to prevent yourself from falling in a situation where you end up with an only option of creating a dummy record?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
使用虚拟记录不如获得正确的约束。
人们经常会忍不住使用它们，因为使用虚拟记录似乎是交付新功能的最快方式（也许有时确实如此），但它们从来不是良好设计的一部分，因为它们隐藏了领域逻辑和数据模型之间的差异。
Using dummy records is inferior to getting the constraints right.
There's often a temptation to use them because using dummy records can seem like the fastest way to deliver a new feature (and maybe sometimes it is), but they are never part of a good design, because they hide differences between your domain logic and data model.
仅当建模者无法轻松更改数据库定义时才需要虚拟记录，这意味着定义和/或数据模型非常糟糕。人们永远不应该陷入应用程序层中必须有特殊代码来处理数据库中的特殊情况的情况。这绝对是一场维护噩梦。
任何好的定义或模型都将允许轻松更改，而不会“影响现有代码”。
[数据库中定义的]所有业务逻辑都应使用 ANSI SQL 约束、检查和规则来实现。 （当然，较低级别的结构已经通过域/数据类型等受到限制，但我不会将它们归类为“业务规则”。）我确保我最终不必仅仅通过这样做来实现虚拟模型。
如果做不到这一点，那么建模者就缺乏知识和经验。或者更高级别的要求（例如规范化）已被打破，这给实施依赖于它们的约束带来了障碍；也意味着建模者失败了。
我从来不需要打破这样的约束，或者添加虚拟记录（而且我已经处理过大量的数据库）。当我修改其他人创建的数据库时，我删除了虚拟记录（和重复项）。
Dummy records are only required when the modeller cannot easily change the Database Definition, which means the definition and/or the data model is pretty bad. One should never end up in a situation where there has to be special code in the app layer to handle special cases in the database. That is a guaranteed maintenance nightmare.
Any good definition or model will allow changes easily, without "affecting existing code".
All business logic [that is defined in the Database] should be implemented using ANSI SQL Constraints, Checks, and Rules. (Of course Lower level structures are already constrained via Domains/Datatypes, etc., but I would not classify them as "business rules".) I ensure that I don't end up having to implement dummies, simply by doing that.
If that cannot be done, then the modeller lacks knowledge and experience. Or higher level requirements such as Normalisation, have been broken, and that presents obstacles to implementing Constraints which are dependent on them; also meaning the modeller failed.
I have never needed to break such Constraints, or add dummy records (and I have worked on an awful lot of databases). I have removed dummy records (and duplicates) when I have reworked databases created by others.
我从来没有遇到过必须这样做的情况。如果您需要这样做，那么您的数据结构有问题，并且会进一步导致报告问题......
I've never run across having to do this. If you need to do this, there's something wrong with your data structure, and it's going to cause problems further down the line for reporting...
使用傻瓜是愚蠢的。
一般来说，你应该致力于在没有它们的情况下使你的逻辑正确。我也见过它们被使用，但只是作为紧急解决方案。您的描述听起来太像将其作为标准做法了。这会带来比它解决的问题更多的问题。
Using Dummies is dumb.
In general you should aim to get your logic right without them. I have seen them used too, but only as an emergency solution. Your description sounds way too much like making it a standard practice. That would cause more problems than it solves.
我认为添加“虚拟”记录的唯一原因是当您的应用程序和数据库设计非常糟糕时。
这绝对不是常见的做法。
如果您的业务逻辑依赖于现有的记录，那么您需要执行以下两件事之一：要么确保在执行该逻辑之前创建正确的记录；要么确保在执行该逻辑之前创建正确的记录。或者，更改逻辑以考虑丢失的信息。
The only reason I can see for adding "dummy" records is when you have a seriously bad app and database design.
It is most definitely not common practice.
If your business logic depends on a record existing then you need to do one of two things: Either make sure that a CORRECT record is created prior to executing that logic; or, change the logic to take missing information into account.
我认为任何不容易区分为“业务逻辑”的情况都是尝试想出更好方法的原因。
您提到“指向类型：Dummy”的事实使我相信您正在使用某种 ORM 来处理数据访问。对于像 NHibernate 这样的 ORM 解决方案来说，一个非常好的检查点（尽管不是唯一的）是你的源代码非常明确地描述了驱动应用程序的数据结构。这不仅允许您在源代码控制下轻松管理数据访问，而且还可以在出现问题时更轻松地进行调试（让我们面对现实吧，这不是问题是否会发生的问题，而是何时发生的问题）。
当您引入某种“拐杖”（例如虚拟记录）时，您就忽略了数据库的意义。数据库可以对您的数据执行规则，以消除对此类事物的需求。我建议您在采用这种技术之前首先查看您的应用程序逻辑。想想你的开发同事或新员工。如果他们需要添加一个功能并且忘记了你的小“虚拟记录”逻辑怎么办？
您在问题中提到自己感到忧虑。跟着你的直觉走。摆脱虚拟记录。
I think any situation where something isn't very easily distinguishable as "business-logic" is a cause for trying to think of a better way.
The fact that you mention "which points a type: Dummy" leads me to believe you are using some kind of ORM for handling your data access. A very good checkpoint (though not the only) for ORM solutions like NHibernate is that your source code VERY EXPLICITLY describes your data structures driving your application. This not only allows your data access to easily be managed under source control, but it also allows for easier debugging down the line should a problem occur (and let's face it, it's not a matter of IF a problem will occur, but WHEN).
When you introduce some kind of "crutch" like a dummy record, you are ignoring the point of a database. A database is there to enforce rules against your data, in an effort to ELIMINATE the need for this kind of thing. I recommend you take a look at your application logic FIRST, before resorting to this kind of technique. Think about your fellow dev's, or a new hire. What if they need to add a feature and forget your little "dummy record" logic?
You mention yourself in your question feeling apprehension. Go with your gut. Get rid of the dummy records.
我必须顺应这里的普遍感觉，反对虚假记录。
将会发生的情况是，新开发人员将不了解它们，也不会编写代码来处理它们，或者删除表并忘记添加新的虚拟记录。
我在遗留数据库中经历过它们，并且看到了上述两种情况的发生。
此外，它们存在的时间越长，取出它们就越困难，并且您必须编写更多代码来考虑这些虚拟记录，如果您在没有它们的情况下进行原始设计，这些虚拟记录可能已被删除。
I have to go with the common feeling here and argue against dummy records.
What will happen is that a new developer will not know about them and not code to handle them, or delete a table and forget to add in a new dummy record.
I have experienced them in legacy databases and have seen both of the above mentioned happen.
Also the longer they exist the harder it is to take them out and the more code you have to write to take into account these dummy records which could probably have been removed if you just did the original design without them.
正确的解决方案是更新您的业务逻辑。
引用您的扩展解释：
因此，一次没有内容的包是无效的，因此业务层强制在包对象中存在内容。这是有道理的。现在，如果现实世界场景发生了变化，那么现在需要有充分的理由来创建没有内容的 Package 对象，那么业务逻辑层就需要更改。
几乎普遍在任何地方使用“虚拟”任何东西都是一个坏主意，并且通常表明实施中存在问题。在本例中，您使用虚拟数据来“遵守”业务层，该业务层不再准确地表示业务的现实世界约束。
如果没有内容的包无效，那么允许“遵守”业务层的虚拟数据是一个愚蠢的黑客行为。本质上，您编写了规则来保护您自己的系统，然后如何尝试规避您自己的保护。另一方面，如果没有内容的包有效，那么业务层不应该强制执行虚假的约束。在这两种情况下，虚拟数据均无效。
The correct solution would be to update your business logic.
To quote your expanded explanation:
So the at one time to a package w/o content was invalid thus business layer enforced existence of content in a package object. That makes sense. Now if the real world scenario has changed such there is now a need VALID reason to create Package objects without content it is the business logic layer which needs to be changed.
Almost universally using "dummy" anything anywhere is a bad idea and usually indicates an issue in implementation. In this instance you are using dummy data to allow "compliance" with a business layer which is no longer accurately representing the real world constraints of the business.
If package without content is not valid then dummy data to allow "compliance" with business layer is a foolish hack. In essence you wrote rules to protect your own system and then how are attempting to circumvent your own protection. On the other hand if package without content is valid then business layer shouldn't be enforcing bogus constraints. In neither instance is dummy data valid.