大家好，我是一名狂熱的資料庫程式設計師，趁著 3.15 的良辰吉日，鼓起勇氣站上了資料庫吐槽大會舞臺，以下故事純屬虛構，如有雷同，請對號入座。
先說說最近的事，我們業務有很多圖片要管理，老闆說讓我選個專業的圖資料庫，還給我推薦了 Neo4j、Nebula、TigerGraph 一堆，讓我好好對比下圖片管理的能力。炸一試，結果沒一個是可以存圖片的，都說他們是用來存物件關係圖，比如粉絲關係、情侶關係、債主關係啊等等。你這不是坑爹嘛？取名字也不帶這樣糊弄老闆的。
說到物件關係就惱火，那些號稱發展了幾十年的關係型資料庫的，真是表裡不一。有個專案我建了很多表的外來鍵關聯，並且還寫了不少關聯多個表的複雜 SQL，想秀秀技能，結果被 DBA 各種 diss，說這種外來鍵和關聯查詢不適合用關聯式資料庫，效能可能會很差，要打回去整改，感覺專案又要延期了。我們那 mysql 關係型資料庫裡一張表已經快有1億條記錄，老闆看到專家建議 mysql 最多放2000萬條記錄，但我現在也沒遇到啥問題，到底是我錯了還是專家說錯了？如果按這建議我得搞幾十張表，業務改造巨大，誰能救救我，我想怎麼把專家先幹了？同事說要不上文件資料庫 MongoDB？說起那個叫 MongoDB 的文件資料庫就鬱悶，你出來走兩步，就一存 json 資料的，憑啥是文件資料庫，也沒看到你哪裡適合存放 word、PDF 文件啊。你那【芒果資料庫】的外號，難道你老闆家種了很多 mango，再搞了專門放芒果的倉庫。還有，我們老闆已經嚷了很久，說趕緊上大資料平臺，不然怎麼能把公司幾百 GB的資料管理好。做好了大資料平臺，我們未來就可能成為下一個 Google、微信，甚至是 ChatGPT。老闆，你說的都對，高瞻遠矚，我想想怎麼多搞些資料，不然我們們那臺 PC 伺服器可能閒得會罷工。關係型資料庫、圖資料庫、文件資料庫，從這名字和實際功能看感覺都是個騙子。資料庫不想再吐槽了，再吐槽下那些資料安全的囧事吧。
最近我那 Navicat 的開發工具又提示過期了，下了個破解版，最後發現藏了病毒，我慌得不敢說啊，找個好用的資料庫開發工具就這麼難嗎？工欲善其事，必先利其器，老闆能不能花點錢，我們們也支援下同行的正版計劃，你看，人們都在知乎上要證明清白了。（能插個廣告嗎？資料庫開發工具，就用ninedata，安全易用）我們那資料庫密碼，已經用了3年，沒變過，大家還經常使用，估計保潔阿姨和快遞小哥都知道了，我也為公司慌啊，感覺那 DBA 兄弟的飯碗遲早會保不住。最後是我們保命的資料庫備份，每次要恢復的時候不是備份失敗，就是恢復出錯，要不就是恢復時間太長，業務接受不了，我都感覺這備份的投資是打水漂了，主要是用來應付領導的。老闆，還有 DBA 兄弟，我先吐這麼多啊，我絕對不會刪庫跑路的，其他人就不敢保證了，你們保重啊！- 圖資料庫不是用來管理圖片，是用來管理物件關聯關係，在社交、風控等領域用得上；
- 關係型資料庫的外來鍵很多坑，在多表關聯也很吃力，尤其是執行計劃用不上合理的索引時；
- MySQL 的2000w記錄上限說法已經過時了，尤其是那個按B樹高度的解釋，關鍵還是看資料結構、SQL 語句和硬體效能，同時定期清理或歸檔歷史資料；
- 文件資料庫不是用來存文件的，是用來存放 JSON 格式的資料，適合比較靈活的 schema 設計；
- 幾百 GB 資料就不要折騰大資料了，一般資料庫或者資料倉儲就挺合適的；
作者是來自 NineData 的資料庫開發工程師，也是10年老 DBA。NineData 的官網地址：，提供企業級資料庫 SQL 開發工具，資料複製、對比、備份等產品，免費使用，無需下載。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024923/viewspace-2939699/，如需轉載，請註明出處，否則將追究法律責任。
