資料庫解凍
2008 年 11 月 24 日
幾年前,我聽程式語言界的人談論由 Java 造成的語言「核子寒冬」。當時的感覺是,每個人都如此趨同於 Java 的運算模型(當時 C# 被視為僅是抄襲),以至於程式語言中的創意都消失了。這種感覺現在正在消退,但或許有一個更重要的解凍可能正在開始,那就是關於資料庫的更長且更深的凍結。
當我開始從事軟體開發專業時,我與幾位宣揚關係資料庫的人共事。我在物件導向的世界中遇到他們。當時許多人預期 OO 資料庫將是資料庫的下一步演進。正如我們現在所知,那並沒有發生。現在關係資料庫已經根深蒂固,以至於大多數專案在開始時就假設有一個 RDBMS。
上週在 QCon,有一連串演講質疑了這個假設。其中一個讓我印象深刻的是 提姆·布雷 的主題演講,他進行了一趟 旅程,探討了資料管理的幾個面向。在這樣做的過程中,他強調了許多有趣的專案。
- Drizzle 是一種關係資料庫,但它避開了許多現代關係產品的機制。我把它當成一個 RISC RDBMS,只支援關係功能集的基本架構。
- Couch DB 是許多分散式鍵值對模型的嘗試之一。雖然這是一個非常簡單的資料模型(實際上只是一個雜湊映射),但這種方法在高流量網站中已變得相當流行。
- Gemstone 是物件資料庫的其中一員,而我發現 Gemstone-Smalltalk 的組合是一個非常強大的開發環境(優於大多數的後繼者)。Gemstone 仍然是一個利基市場的參與者,但可能會透過 Maglev 獲得更多關注,Maglev 是將其方法(基本上是資料庫和虛擬機器的融合)帶入 Ruby 世界的一個專案。
除了這個演講之外,還有一個由 Kresten Krab Thorup 主持的關於替代資料庫的完整 主題。在那裡提到的其他工具之一是 Neo4J,這是一個圖形(網路)資料庫工具,獲得了 Jim Webber 的罕見讚譽。
對於這些產品,一個自然的問題是,當 ODBMS 失敗時,為什麼它們應該盛行。環境中有哪些改變可以解除關係式資料庫的控制?關於為什麼關係式資料庫如此盛行,有很多假設,我的看法是,它們的盛行並非由於它們在資料管理中的角色,而是由於它們在整合中的角色。
對於當今許多組織而言,整合的主要模式是 共用資料庫整合,其中多個應用程式透過使用共用資料庫進行整合。當您擁有這些 整合資料庫 時,重要的是所有這些應用程式都可以輕鬆取得這些共用資料,因此 SQL 扮演了非常重要的角色。SQL 作為大多數標準查詢語言的角色,一直是關係式資料庫盛行的核心。
資料庫空間的升溫來自於整合的替代方案,特別是網路服務的興起。在各種標語下,應用程式透過 HTTP 傳遞文字(大多數是 XML)文件來彼此交談,這股運動正在興起。網路,無論是網際網路或內部網路形式,都讓這種整合模式比 SQL 更加普遍。這是一件好事,我從來不喜歡多個應用程式透過共用資料庫緊密結合的方法,您無法獲得比這更大的封裝破壞。
如果您將整合協定從 SQL 切換為 HTTP,現在表示您可以將資料庫從 整合資料庫 變更為 應用程式資料庫。這種改變是深遠的。在第一步中,它支援一個更簡單的物件關係對應方法,例如 Ruby on Rails 採取的方法。但此外,它打破了關係式資料模型的束縛。如果您透過 HTTP 整合,應用程式如何儲存自己的資料就不再重要,這反過來表示應用程式可以選擇一個符合自己需求的資料模型。
我不認為這表示關係式資料庫將會消失,畢竟它們是許多情況下的正確選擇。但這確實表示現在應用程式開發人員應該思考什麼才是符合他們需求的正確選項。隨著非關係式專案的普及和成熟,將會有越來越多的人選擇其他選項。