我曾为拥有大量不同的中小型项目的客户工作，每个项目都通过正确定义的接口相互交互以共享数据，但不读取和写入同一个数据库。每个人都有自己独立的数据库、自己的缓存、自己的文件服务器/系统，他们有专门的访问权限，所以他们从来没有引起任何问题。其中一个客户是移动内容供应商，因此他们很幸运，不必面对日常业务应用程序所面临的同样问题。他们可以创建所有这些单独的隔间，在这些隔间中，他们的组件可以愉快地与其他组件隔离开来。
但是，对于许多业务应用程序来说，这是不可能的。我与一些客户合作过，其中一个应用程序我正在为其提供生产支持，每小时都会出现“不良数据问题”。是的，就是这么疯狂。来自其中一个实例的一些数据记录（当然低于生产环境）会在几周前运行，并导致其他一些用户的数据损坏。然后，必须编写一个数据脚本来解决这个问题。我已经看到这个客户发生了很多事情，我不得不问。
我已经看到其他客户以适度的速度发生这种情况，但这个似乎只是不正常。
如果您使用的业务应用程序通过读取和写入同一数据库来共享大量数据，那么“不良数据问题”在您的环境中是否常见？
不良数据问题一直在发生。唯一合理有效的防御是一个设计合理、规范化的数据库，最好只通过存储过程与外界交互。
这就是为什么将所需的数据规则放在数据库级别而不是应用程序中很重要的原因。（当然，许多系统似乎也不在应用程序级别上打扰。）
似乎很多设计数据导入的人在将数据放入系统之前都不会费心清理数据。当然，很难找到所有可能的方法来弄乱数据，我已经做了很多年的导入，有时我仍然会感到惊讶。我最喜欢的是他们的数据输入人员显然不关心字段名称的公司，当第一个字段填满时，应用程序就转到下一个字段。我的名字如下：姓氏字段中的“McDonald, Ja”和名字字段中的“mes”。
我从很多很多客户和供应商那里导入数据。在我开发的数百个不同的导入中，我只能想到一两个数据是干净的。由于某种原因，电子邮件字段似乎特别糟糕，并且通常用于注释而不是电子邮件。给“他的秘书是个性感的金发女郎”发邮件真的很难。
我不认为您在谈论不良数据（但您回答评论中提出的各种问题只是礼貌）而是无效数据。例如，“9A！” 存储在应该包含 3 个字符的 ISO 货币代码的字段中可能是无效数据，并且应该在数据输入时被捕获。坏数据通常被认为等同于由磁盘错误等引起的损坏。前者很常见，取决于数据输入应用程序的质量，而后者则很少见。
是的，很常见。让客户了解问题的严重程度是另一回事。在一个客户那里，我不得不编写一个应用程序来分析他们的数据库，并且每次遇到与他们自己发布的数据格式不匹配的记录时都会发出哔哔声。我带着安装了他们的 DB 的笔记本电脑去开会并运行程序，然后看着桌子上的所有人转过头来盯着他们的 DBA，而我的机器在后台疯狂地发出哔哔声。没有什么比在他自己的问题中磨蹭客户的鼻子来获得关注更有趣的了。
我假设“不良数据问题”是指“不满足所有适用业务限制的数据问题”。
它们只能是两件事的结果：数据库设计者糟糕的数据库设计（即：在数据库定义中无意或更糟糕地故意遗漏了完整性约束），或者 DBMS 无法支持更多复杂类型的数据库约束，结合程序员编写的有缺陷的程序来强制执行不支持 dbms 的完整性约束。
考虑到糟糕的 SQL 数据库在完整性约束方面有多差，并且考虑到普通“现代程序员”的数据管理知识水平很低，是的，这样的问题无处不在。
如果由于用户在复杂的数据库更新过程中关闭了他们的应用程序而导致数据损坏，那么事务就是你的朋友。这样您就不会在 Invoice 表中获得条目，但在 InvoiceItems 表中没有条目。除非在流程结束时提交，否则所有所做的更改都会回滚，