資深IT人員告訴你,為什麼DOGE總是鬧笑話

2025-02-24 | 來源: 信息正義 | 轉到微信 | 有0人參與評論 | 字體: 放大縮小 | 收藏 | 打印

記得 2020 年大選時，網上盛傳某個州選民數據庫裡很多選民生日是 1800 年 1 月 1 日或 1900 年 1 月 1 日。於是有人說，這還了得，200 多歲的人還在投票！

說實話，我當時一看就明白，這一定是一個派特別用途的特定數值。果然，後來聽見 CNN 電台裡解釋說這是個占位符(placeholder)，說是用這個日子代表已經投過票的人。當時我也對人說，我猜是個特定值。但馬上有人說，從來沒見過設計數據庫時，生日欄不輸入生日信息，卻派這樣的用途。不可能！

我只能說，這樣說話的人不懂得數據庫前台與後台的區別。這種實踐在數據庫應用裡非常普遍。你沒聽說過是因為你只看得見前台，而做後台的人不需要告訴你這些“肮臓”的東西。

沒有人會在設計數據庫的時候就決定把生日欄派這個用場。這樣的“設計”都是慢慢演變出來的。任何企業或機構，業務范圍或運作方式隨時會發生變化，於是對數據庫就會有新的要求。一個數據庫投入應用後，結構不能隨便改。即便現在數據庫已經越來越機動靈活了，改變的空間也有限，這就必須在現有條件下發揮創造性來滿足業務要求。

我不知道上面例子的真實情況是怎樣的，但我可以從專業角度猜測。下面就是幾種數據庫應用中經常發生的只有在後台才看得見的“不尋常”現象（其中包括但不限於針對上面例子的情況）。

1）數據庫後台有不止一個生日欄，分布在不同的表格裡。

這就有了機動性，可以保留一個生日欄作為真正的生日，其他派別的用途。上面例子就很可能是這種情況，凡是已經投過票的，就在這個多余的生日欄輸入特定的日子，如果這個選民再次來投票，系統就會拒絕。

別問我為什麼會有一個以上生日欄。這個世界稀奇古怪的事情很多，包括數據庫的設計或數據庫裡的數據。大概率是從不同地方數據遷移過來匯總的結果，為了某種原因——比如同一個人不同來源的數據給出不同的生日——不得不給兩個、三個生日欄，把不同來源的生日存在不同地方，日後慢慢清理，最後全部輸入一個地方。

國家為什麼會失敗:中譯本刪改部分就是最佳答案

《父母愛情》競爭安傑飾演者,為什麼王茜華會輸給了梅婷?

為什麼抗日劇那麼多,愣是沒有啥作品能超越《亮劍》的?

2）有一種可能，以前對搬離本州或故世的選民，都是采用刪除的做法。後來業務要求變了，需要保留記錄，只是將這些人標為不能投票。

為了滿足新的業務要求，做後台設計的人決定用生日欄來做標記，凡是搬離的選民，就把生日改為 1800 年 1 月 1 日；凡是去世的，就輸入 1800 年 1 月 2 日；凡是犯罪被剝奪投票權的，生日一律是 1800 年 1 月 3 日……關鍵是選擇一個“不可能”的日子，這樣就不會與真實的日子混淆。

這裡就再現了我前面說的非專業人員看不懂後台數據的情況。要從後台調出今年的合格選民，你必須知道選擇條件，必須排除那些生日是特殊日子的人。不知道的人直接去後台看數據，就以為自己發現了驚人的秘密。事實上，那些選民是不會獲得投票資格的。如果是從 app 裡看，你根本不會看見不合格選民，因為被系統過濾掉了。在 app 上，可能只有有特別權限的人才能看見不合格選民。

3）也有可能，數據庫原先的設計是，投票記錄表格只記錄最近一次選舉的投票。系統也不保留歷史投票記錄，每次選舉就抹去以前的記錄，重新開始。但是，後來又要求保留所有投票記錄。於是，名稱為“最近一次選舉投票記錄”的那個表格裡，一個選民會有很多記錄。讓事情更糟糕的是，那個表格沒有投票日這一欄，也沒有其他可以用作類似用途的內容，這樣的話，要調出最近一次投票記錄就必須通過與其他表格中的記錄相連，甚至可能需要利用系統內在的“時間戳”(timestamp)才能調出正確的內容。當限制條件在另外的表格裡時，僅僅看一個表格，就不可能知道這一筆記錄是不是“有效”。至於需要利用系統時間戳的，這是“不可見”的東西，外行在後台絕對看不出名堂，相反還會“發現”，居然有那麼多人在一次選舉中多次投票！

數據庫是個特別的東西

數據庫有其特殊性，也有自己特殊的難度，特別是做系統的改朝換代。我做過好幾個大型數據遷移項目，深知把數據從舊系統遷移到一個結構完全不同的新系統是一個非常挑戰的工作。稍有不慎就會犯毀滅性的錯誤。

以顯示員工名單為例，如果一個應用程序忘記考慮“在職與否”那個欄目，把不該包括的名單都顯示了出來，只需要在程序裡加一個條件就改正了。這樣的錯誤，除了面子不好看，不會有大傷害。但如果是數據遷移把這一欄漏了，就再也沒辦法區分員工的在職狀態了。