無資料庫管理員
2013 年 2 月 25 日
在許多組織中,預期任何永久資料都將儲存在由中央資料庫管理小組管理的關係式資料庫中。這種集中控制有各種原因,通常以使用 IntegrationDatabases 為中心。中央資料小組擔心排除格式錯誤的資料、會減慢重要共用資源速度的查詢,以及企業中一致的資料模型。
這些目標可能是值得的,但其中一個後果是儲存資料的繁文縟節相當多。我經常聽到有人抱怨變更訂單需要數週才能將欄位新增到資料庫中。對於習慣於短週期演化式設計的現代應用程式開發人員來說,這種繁文縟節太慢了,更別說太惱人了。
因此,應用程式開發小組告訴我使用 NoSQL 資料庫 來繞過資料庫管理員。他們在此使用「單純資料儲存庫」,而不是「適當的資料庫」是有幫助的。這樣資料庫管理員就可以置身事外,通常不會被告知或樂於不關心。 [1]

這一切都有好有壞。好處是,這有助於打破許多組織應用程式開發的瓶頸,這通常令人困擾。應用程式開發人員和資料庫專業人員之間的悲慘鴻溝會造成許多問題,而資料庫管理員社群中許多 現代 開發 技術 的採用率不佳,阻礙了許多開發。 共用資料庫 是一種不佳的整合機制,而無資料庫管理員開發有助於推動以 網路服務 作為整合基礎。 [2]
負面方面是,基於社交原因使用技術通常會導致技術使用不當。不難想像人們在關係式 應用程式資料庫 會是更好的選擇時,使用 NoSQL 資料庫來避免資料庫管理員。資料通常是重要的資產,而繞過資料庫管理員小組也可能意味著繞過知道如何備份和保護有價值資料的作業小組。
當然,真正的答案是與資料專業人員合作,就像 devops 運動一樣。造成許多繁文縟節的是團隊之間的障礙,很少資料團隊是由魔鬼組成的。我們已經看到邀請資料庫管理員參加利害關係人會議的成功,他們可以在會議中參與應用程式的廣泛目標。我們也曾有 NoSQL 專案,我們向資料庫管理員伸出援手,協助他們瞭解這項新技術,並在支援資料需求方面獲得有價值的幫助。因此,儘管 NoDBA 策略有時很合適,但參與通常會更好。
致謝
一如往常,我發現我們在內部清單上對本文草稿的討論非常有趣。我特別突襲了 David Pattinson 的貢獻。備註
1: 在這種情況下,使用 MongoDB 似乎特別常見,原因是 MongoDB 易於安裝、設定和使用。
2: 對變更要求反應緩慢的一個很大原因是,許多現有資料庫本質上是大型依賴性網路中心的複雜舊式應用程式。這些資料庫脆弱且未經測試 (令人厭惡),因此負責照料它們的資料庫管理員會謹慎變更也就不足為奇了。這樣的系統甚至會讓最聰明的開發人員對變更感到害怕。