Database 坏数据问题是常见的吗？

我为客户工作过，他们有大量不同的中小型项目，每个项目都通过正确定义的接口相互交互以共享数据，但不读取和写入同一数据库。每个人都有自己独立的数据库、自己的缓存、自己专用的文件服务器/系统，因此他们从未造成任何问题。其中一个客户是移动内容供应商，因此他们很幸运，他们不必面对日常业务应用程序所面临的问题。它们可以创建所有这些独立的隔间，在这些隔间中，它们的组件可以快乐地与其他组件隔离

但是，对于许多业务应用程序，这是不可能的。我曾与一些客户合作，其中一个应用程序是我负责生产支持的，每小时都有“坏数据问题”。是啊，太疯狂了。其中一个实例的一些数据记录（当然低于生产记录）可能在几周前就已经运行了，并导致其他用户的数据损坏。然后，必须编写一个数据脚本来解决此问题。我在这个客户身上看到了太多这样的事情，我不得不问

我在其他客户身上看到过这种情况以中等速度发生，但这一次似乎出了问题

---

如果您使用的业务应用程序通过读写同一数据库共享大量数据，那么“坏数据问题”在您的环境中是否常见？

坏数据问题总是会发生。唯一合理有效的防御措施是设计合理、规范化的数据库，最好只通过存储过程与外部世界进行交互。

是的，非常常见。让客户了解问题的严重程度是另一回事。在一位客户那里，我不得不编写一个应用程序，分析他们的数据库，每次遇到与他们自己发布的数据格式不匹配的记录时，都会发出嘟嘟声。我把装有数据库的笔记本电脑带到一个会议上，运行程序，然后看着桌上所有的人转过来盯着他们的数据库管理员，而我的电脑在后台疯狂地发出嘟嘟声。没有什么比把客户的鼻子磨在他自己的问题上更吸引人的了。

我不认为你说的是糟糕的数据（但你回答评论中提出的各种问题是礼貌的），而是无效的数据。例如，“9A！”存储在应该包含3个字符的ISO CCURNCY代码的字段中的数据可能无效，并且应该在数据输入时捕获。坏数据通常被视为等同于磁盘错误等导致的损坏。前者非常常见，具体取决于数据输入应用程序的质量，而后者非常罕见。

这就是为什么将所需的数据规则放在数据库级别而不是应用程序级别很重要的原因。（当然，似乎许多系统在应用程序级别也不麻烦。）

另外，似乎很多设计数据导入的人在将数据放入系统之前都懒得清理数据。当然，很难找到所有可能的方法来搞乱数据，我已经做了很多年的导入工作，有时还是会感到惊讶。我最喜欢的是一家公司，他们的数据输入人员显然不关心字段名，当第一个字段已满时，应用程序只转到下一个字段。我在姓氏字段中有“McDonald，Ja”这样的名字，在名字字段中有“mes”这样的名字

我从许许多多的客户和供应商处导入数据。在我开发的数百种不同的导入中，我只能想到一两种数据是干净的。出于某种原因，电子邮件字段似乎特别糟糕，通常用于便笺而不是电子邮件。给“他的秘书是性感金发女郎”发电子邮件真的很难。我想“坏数据问题”是指“不满足所有适用业务约束的数据问题”

它们只能是两件事的结果：数据库设计者糟糕的数据库设计（即：在数据库定义中无意或更糟糕的是故意遗漏完整性约束），或者DBMS无法支持更复杂类型的数据库约束，与程序员编写的有缺陷的程序相结合，以强制实施dbms不支持的完整性约束

---

考虑到SQL数据库在完整性约束方面有多差，并且在平均“现代程序员”中数据管理的知识水平很差，是的，这些问题随处可见。

< P>如果数据获取被破坏，因为用户在复杂数据库更新的中间关闭应用程序，那么事务就是您的朋友。这样，您就不会在发票表中获得条目，但在InvoiceItems表中不会获得条目。除非在流程结束时提交，否则所做的所有更改都将回滚，

您能定义“坏数据”吗？数据是如何损坏的？导致数据损坏的原因是什么？举一个你所说的坏数据的例子会很有用。你能稍微澄清一下你的例子吗？我不确定您是说在一个数据库中运行多个模式以支持prod集成测试环境，还是说您的意思是，查询多个数据库的生产流程接收到的坏测试数据会交叉感染您。或者别的什么@Lazarus如果你认为某个问题与编程无关，请投票结束。不要使用“非编程相关”标签。坏数据与编程密切相关。