常見的不良數據問題？

Question

我曾爲有大量不同的中小型項目的客戶工作，每個客戶都通過正確定義的接口互相交互以共享數據，但不能讀取和寫入同一數據庫。每個人都有自己獨立的數據庫，他們自己的緩存，他們自己的文件服務器/系統，他們有專門的訪問權限，所以他們從來沒有造成任何問題。其中一個客戶是移動內容供應商，所以他們很幸運，因爲他們不必面對日常商業應用所遇到的問題。他們可以創建所有這些單獨的隔間，在這些隔間中，他們的組件愉快地與其他隔離。

但是，對於許多商業應用程序來說，這是不可能的。我曾與幾個客戶合作過，其中一個客戶的應用程序正在進行生產支持，每小時都有「不良數據問題」。是的，這是瘋狂的。其中一個實例的某些數據記錄（當然低於生產）將在幾周前運行，並導致其他用戶的數據被損壞。然後，必須編寫一個數據腳本來解決這個問題。我已經看到，這個客戶發生了這麼多事情，我不得不問。

我已經看到這種情況發生在與其他客戶適中的速度，但這似乎是失靈。

如果您正在使用通過讀寫同一數據庫共享大量數據的業務應用程序，那麼您的環境中常見的是「不良數據問題」嗎？

Answer 1

不良數據問題一直在發生。唯一合理有效的防禦是設計正確的規範化數據庫，最好只通過存儲過程與外部世界進行交互。

Answer 2

是的，很常見。讓客戶瞭解問題的嚴重程度是另一回事。在一個客戶中，我不得不求助於編寫一個應用程序來分析他們的數據庫，並在每次創建一個與他們自己發佈的數據格式不匹配的記錄時進行瀏覽。我把安裝了數據庫的筆記本電腦帶到了一個會議中，然後運行了程序，然後看着桌子上的所有人都旋轉着盯着他們的DBA，而我的機器在後臺瘋狂地嘟be着。沒有什麼比在自己的問題中磨礪客戶的鼻子以獲得關注。

Answer 3

我不認爲你在談論壞的數據（但它只會對你回答評論中提出的各種問題很有禮貌），但是無效的數據。例如，'9A！'存儲在應該包含3個字符的ISO ccurrency代碼的字段中可能是無效數據，並且應該在數據輸入時捕獲。不好的數據通常被認爲是相當於由磁盤錯誤等引起的腐敗。前者是相當普遍的，這取決於數據輸入應用程序的質量，而後者是非常罕見的。

Answer 4

這就是爲什麼將所需數據規則放在數據庫級別而非應用程序非常重要的原因。 （當然，很多系統似乎也不會在應用程序級別上打擾）。

似乎很多設計數據導入的人，在將數據放入它們之前不打擾數據導入系統。當然，很難找到所有可能的方法來搞亂數據，我已經做了多年的進口，有時候我仍然很驚訝。我最喜歡的是公司，他們的數據輸入人員顯然不關心字段名稱，並且應用程序在第一個字段完整時才轉到下一個字段。我姓氏如：姓氏字段中的「McDonald，Ja」和名字字段中的「mes」。

我從許多客戶和供應商處進行數據導入。在我開發的數百種不同的進口產品中，我只能想到一兩個數據是乾淨的。出於某種原因，電子郵件字段似乎特別糟糕，通常用於筆記而不是電子郵件。真的很難發郵件給「他的祕書是熱的金髮女郎。」

Answer 5

我假定「不良數據問題」是指「不符合所有適用業務限制的數據問題」。

它們只能是兩件事情的後果：數據庫設計者對數據庫的錯誤設計（即：數據庫定義中無意或者甚至有意刪除完整性約束）或者DBMS不能以支持更復雜的數據庫約束類型，再加上程序員編寫的有缺陷的程序，以強制執行dbms不支持的完整性約束。

鑑於SQL數據庫在完整性約束條件下的表現有多差，並且考慮到平均「現代程序員」對數據管理的瞭解水平較低，所以這些問題無處不在。

Answer 6

如果由於用戶在複雜的數據庫更新過程中關閉其應用程序而導致數據損壞，則交易是您的朋友。這樣，您不會在Invoice表中獲得條目，但在InvoiceItems表中沒有條目。除非在流程結束時提交，否則所做的更改將回滾，