資料庫真爛的 幕後黑手 “們”

開頭還是介紹一下群，如果感興趣polardb ,mongodb ,mysql ,postgresql ,redis 等有問題，有需求都可以加群群內有各大資料庫行業大咖，CTO，可以解決你的問題。加群請聯絡 liuaustin3.

新年已經過了，各種吉利的詞彙已經過去，我們還的面對現實，現實中充斥著各種的對於資料庫不好用或者管理資料庫的無能者的各種侮辱性詞彙。

今天我們就來看看導致資料庫不好用，不能用，的那些幕後黑手是那些，你能想到一個資料庫不好用的 黑手都是怎麼組成的？？？

黑手 1   開發

開發是資料庫的幕後黑手，或者把幕後去掉，黑手，黑手的產生源於幾種型別

1   不會型別：此種型別的開發根本對資料庫是一無所知，只是知道 I U D ，其他的一概不知，這種型別的開發者實際上對於資料庫是一種茫然的狀態，資料庫對他們一直很神秘，發現各種各種的問題後，首先懷疑出現問題的一定不是自己，而是資料庫。 這樣的開發者們一直以自我為中心，去設想這資料庫應該這樣，資料庫應該那樣，而從來不去讀讀資料庫的官方檔案。

2  半瓶子型別：這種型別的開發者實際上對於資料庫已經有了幾年的使用經驗，但經驗的積累僅限於一些簡單的資料庫使用中的開發問題的解決，並沒有大局觀和整體觀，他們的眼界侷限在一個表，一個庫而已，對於一些事務的問題，原子性的問題，還停留在理論階段，例如SQL SERVER 是不是 出現事務問題就全部回滾，MYSQL 在什麼情況下事務出現問題，不全部回滾，RR, RC 之間的區別是什麼，是一概不知。出現問題，基本還停留在資料庫有問題的階段，但有的時候會心虛。

3  經驗主義者：這類開發屬於有了10多年開發經驗的開發者，對於資料庫的一些使用的特點能講出一些 條條框框，如資料庫不要使用大事務，資料庫對於表設計的行列的寬度有一些要求，對於欄位的大小也有一定的理解的程度，但是經驗主義者的問題在於，知識不更新，MYSQL 8 都多少年了，對於MYSQL的認知還活在 MYSQL 5.X的知識領域，基於這樣的經驗，讓開發對於資料庫的使用不能與時俱進，還是在曾經的那些年。

以上三種是常見的開發中，對於資料庫使用出現問題後，經常埋怨資料庫出現問題的常見開發型別。

黑手 2  架構

提到架構，這又是另一種坑害資料庫的，等級更高的一群人，這群人有幾個可以總結的出的對於資料庫使用中出現誤區的特性。

1  架構經驗循規蹈矩型：這類架構人員對於資料庫的知識比上面的3類要深的多，對於資料庫的使用有自己的一定見解，但有些見解是偏頗的，如 資料庫使用 ORACLE 一定比 MYSQL 要強，PG 不能用，MOGNODB 是禍害等等一些理念根深蒂固，一個資料庫用到 “春蠶到死絲方盡” 的地步，幹什麼都是ORACLE ，ORACLE , ORACLE ，其他資料庫都是垃圾的思維模式，當然這樣的 老架構基本上都在那些單位 ，大家也都知道。

2  創新性架構：  這類架構和上面的架構是水火不容，資料庫型別什麼新用什麼，TIDB ， Cassandra, Couchbase , Yugabytedb 那個資料庫大家沒有用過，那麼就是極好的，反正什麼都想試試，什麼都是聽說，完全鄙視因循守舊的那些 老架構，想自己蹚出一條 架構設計中通往  “天堂” 的路。 這些架構在那些單位，大家估計也都知道。

3  怎麼都是錯的架構：  這種型別和上面的兩種比較，更是可恨，前兩種出事情一個是一般專案出不了大事，一個是出事會趁早，而怎麼都是錯的架構一般是不出事，出事就是大事，也是將DBA 推進火坑的最佳人選。

他們選擇資料庫是怎麼不適合這個業務，我就用那種的型別，如儲存大型資料如JSON ，非要MYSQL  PG  ORACLE 此種資料庫不用，而涉及到大事務，事務敏感的部分，又開始使用MONGODB ，做聚合用MYSQL ，超高併發用PG，不該分庫非要分庫，該分表就照著一個表用死。最後流行一句，什麼垃圾資料庫的一般也是從這樣的人嘴裡流出的。
  

黑手  3  領導

領導，本來不想多說什麼，實際上很多公司的資料庫定性都是領導，來注意我的口型， 領導， 來決定，恰恰就是這樣的領導，害死人，不懂，不懂，不懂是他們的特性，被蛇咬是一次性的，如某個專案使用了MYSQL 失敗了，那麼以後什麼專案都不能用MYSQL ，MONGODB 看到網上說MONGODB 不安全，有資料洩露，只看標題，不看內容，然後MONGODB 就在公司了滅絕了，這種型別的黑手是最可恨的，可是你還無法和他辯駁，只能眼睜睜的看著他胡來。

黑手  4   沒有資料生態和資料生命週期的業務，專案經理，產品經理

說到這裡，可能你就會疑問，怎麼資料庫的問題都弄到業務去了，呵呵我說完你就知道他們的可恨之處了。

在產生一個專案的情況下必須對於成本有考慮，上面這些人，根本沒有概念，對於專案本身的資料承載的期限，根本沒有任何的想法，貌似資料就是會一直存在，至於怎麼儲存，儲存多久， 在他們心裡就是永久。

資料庫不是資料倉儲，資料庫不是資料倉儲，資料庫不是資料倉儲，這點的說三遍，一個專案的資料的時間要有期限，這個必須是在專案的產生時就要有一個定義的，而不是把這個問題推到資料庫本身，資料庫隨著資料的堆積，效能會持續下降，成本會持續增高，而最終背鍋的還是 DBA ，怎麼連一個資料庫都管理不好，這個鍋一般的DBA 是一定會背上的。

那麼說了這些禍害，我們們也的從自己身上找原因，如果你對一個資料庫本身都不熟悉，不明瞭，那麼自然就會產生上述的結果，如果你在接手一個專案的情況下，瞭解專案的特色，開發的特色，以及整體專案的 “好” “爛” 的程度，此時你就會選擇出正確的資料庫來對應這些 過去，現在，未來 好爛的應對手段，給出一整套拯救措施。

資料---資料庫---資料處理---資料倉儲--經濟價值--成本

好的DB ，是要有一整套資料處理的思維掛念，而不是天天關心細枝末節，而放任上面這些人，胡作非為，最終獲得  你 “好爛” 的稱號。