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