在過去十年中，我們開發並改進了許多技術，讓資料庫設計能夠隨著應用程式開發而演化。這對於敏捷方法來說是非常重要的功能。這些技術仰賴將持續整合和自動化重構應用於資料庫開發，以及資料庫管理員和應用程式開發人員之間的密切合作。這些技術適用於前置製作和已發布的系統，以及全新專案和舊有系統。

我和同事 Badri 關於六角形架構及其在 Rails 應用程式中扮演的角色的對話影片。在第一部影片中，我們討論六角形架構的意義，以及這如何影響持久化架構中 Active Record 和資料對應器模式之間的選擇。在第二部影片中，我們更廣泛地探討 Rails 在應用程式中應扮演的架構角色 - 你應該將它視為平台還是元件組件。

我們在 2012 年倫敦 QCon 大會的主題演講探討了資料在我們生活中扮演的角色（而且它所做的不只是變得更大）。我們首先探討資料世界的變化方式：它正在成長、變得更加分散和互連。然後我們轉向產業的回應：NoSQL 的興起、轉向服務整合、事件來源的出現、雲端和具有更重要視覺化角色的新分析的影響。我們快速了解資料現在如何使用，特別強調 Rebecca 在開發中國家的資料。最後，我們考慮所有這些對我們作為軟體專業人員的個人責任的意義。

在 goto Aarhus，我們針對 NoSQL 的一些實際經驗進行探討。我受邀進行一場開場演講，說明 NoSQL 資料儲存的基本原則。我談到了 NoSQL 的起源、NoSQL 資料模型的形式、許多 NoSQL 資料庫考量一致性的方式，以及多語持久性的重要性。

近年來，關於無架構資料優點的討論越來越多。無架構是對 NoSQL 資料庫 感興趣的主要原因之一。但無架構涉及許多細微差別，無論是資料庫還是記憶體中資料結構。這些細微差別存在於無架構的意義，以及使用無架構方法的優缺點中。

Pramod Sadalge 領導了敏捷資料庫技術的開發，我們現在習慣在 Thoughtworks 使用這些技術。SE Radio 採訪我們，了解我們如何使用這些技術與使用資料庫的應用程式一起反覆演化資料庫的設計。我們討論如何將資料庫納入持續整合系統，如何透過可重複的腳本遷移進行資料庫變更，以及資料庫重構如何運作。

一份關於企業資料儲存未來的資訊卡，主要寫給參與應用程式開發管理的人員。說明為什麼關係資料庫一直是主流，為什麼 NoSQL 挑戰了這個假設，並概述多語持久性的未來，其中將根據不同的需求，為應用程式使用多種資料儲存技術。

在過去的幾十年中，我們看到資料庫導向軟體開發人員和記憶體中應用程式軟體開發人員之間的差距越來越大。這導致許多關於如何使用資料庫功能（例如 SQL 和儲存程序）的爭議。在本文中，我將探討是否將業務邏輯放在 SQL 查詢或記憶體中程式碼中的問題，主要考慮一個簡單但豐富的 SQL 查詢範例的效能和可維護性。

當我們處理 精餾 NoSQL 時，第一個浮現在腦海中的主題之一是 NoSQL 資料庫使用與關聯模型不同的資料模型。我所看過的大多數來源都至少提到了四組資料模型：鍵值、文件、欄位家族和圖形。觀察這個清單，前三者之間有很大的相似性 - 它們都有一個基本的儲存單元，它是一個緊密相關資料的豐富結構：對於鍵值儲存，它是值，對於文件儲存，它是文件，對於欄位家族儲存，它是欄位家族。在 DDD 術語中，這組資料是一個 DDD_Aggregate。

我使用術語應用程式資料庫來表示由單一應用程式控制和存取的資料庫（與 整合資料庫 相對）。由於只有一個應用程式存取資料庫，因此可以特別定義資料庫以使該應用程式的需求易於滿足。這會產生一個更具體的架構，通常比 整合資料庫 更容易理解，而且通常較不複雜。

資料湖是本十年出現的一個術語，用於描述 大數據 世界中資料分析管線的重要組成部分。這個想法是為組織中任何可能需要分析的人員提供所有原始資料的單一儲存。一般來說，人們使用 Hadoop 來處理資料湖中的資料，但這個概念比 Hadoop 更廣泛。

我早期最喜歡的書之一是 Tsichritzis 和 Lochovsky 的資料模型書籍。這本書討論了不同的資料思考模型，特別是當時討論最多的三個模型：關聯資料模型、階層資料模型 和 網路資料模型。

當我談論資料庫以及它們如何與應用程式相關時，我發現區分兩種資料庫樣式很有用：應用程式資料庫 和 整合資料庫。兩者之間的差異在於資料庫是否受控且封裝在單一 應用程式邊界 內。

幾年前，我聽程式語言人士談論由 Java 造成的語言「核子寒冬」。當時的感覺是，每個人都如此趨同於 Java 的運算模型（C# 在當時被視為僅是山寨版），以至於程式語言的創意消失了。這種感覺現在正在消退，但更重要的解凍可能正在開始，也就是思考資料庫的更長更深的凍結。

Datensparsamkeit 是德語單字，很難適當地翻譯成英文。這是一種關於我們如何擷取和儲存資料的態度，表示我們只應處理我們真正需要的資料。

階層資料模型以階層或樹狀結構組織。早期的資料庫和程式設計資料結構通常使用階層模型，但這些模型後來不受青睞。在資料庫領域，關聯資料模型 成為主流，而對於大多數記憶體內程式設計，網路資料模型 則佔主導地位。這是因為階層雖然是一種簡單的組織工具，但當資料變得更複雜時，它就會崩潰。

內存資料庫是一種完全在主記憶體中運作的資料庫，不會接觸到磁碟。它們通常以嵌入式資料庫的形式執行：在程序啟動時建立，嵌入在該程序中執行，並在程序結束時銷毀。

與任何職業一樣，軟體開發也有其常被遺忘的活動，這些活動通常被忽略，但在最不恰當的時刻會反咬一口。其中之一就是資料遷移。

整合資料庫是一種資料庫，可作為多個應用程式的資料儲存，從而整合這些應用程式中的資料（與 應用程式資料庫 相反）。

當人們啟動企業應用程式時，最早出現的問題之一就是「我們如何與資料庫對話」。如今，他們可能會問一個稍有不同的問題「我們應該使用哪種類型的資料庫 - 關係式資料庫還是這些 NOSQL 資料庫之一？」。但還有另一個問題需要考慮：「我們是否應該使用資料庫？」

網路資料模型將資料結構化為記錄類型，並使用指標連結允許在一個記錄和另一個記錄之間導航。因此，要查詢網路資料模型，您從一個記錄開始，並在指標參考之間移動。

在許多組織中，預期任何持久性資料都將儲存在由中央資料庫管理小組管理的關係式資料庫中。這種集中控制有各種原因，通常集中在使用 整合資料庫。中央資料小組擔心排除格式錯誤的資料、可能會減慢重要共享資源的查詢，以及整個企業中一致的資料模型。

這些目標可能是值得的，但它們的一個後果是儲存資料的相當繁瑣。我經常聽到關於變更訂單的抱怨，這些變更訂單需要數週時間才能將一欄加入資料庫。對於習慣於短週期演化設計的現代應用程式開發人員來說，這種繁瑣太慢了，更不用說太煩人了。

因此，應用程式開發小組告訴我使用 NoSQL 資料庫 來繞過資料庫管理員。他們使用的是「單純的資料儲存」，而不是「適當的資料庫」，這很有幫助。這樣資料庫管理員就可以被排除在外，通常不會被告知或樂於不關心。

當我們開始撰寫 Nosql 精華 時，我們面臨一個棘手的難題 - 我們在寫什麼？什麼才是 NoSQL 資料庫？這個概念沒有明確的定義、沒有商標、沒有標準組織，甚至沒有宣言。

幾個月前，我在倫敦參加 QCon 會議時，似乎每場演講都包含一些對物件/關聯式對映 (ORM) 工具的尖酸評論。我想我應該更仔細閱讀寄給講者的會議電子郵件，裡面肯定有東西告訴我們每 45 分鐘至少要對 ORM 鄙視一次。但正如你所見，我想對這種 ORM 仇恨反擊一下 - 因為我覺得很多都是不合理的。

2006 年，我的同事 Neal Ford 創造了 多語程式設計 一詞，用來表達應用程式應該使用多種語言編寫，以利用不同的語言適合解決不同問題的事實。複雜的應用程式結合了不同類型的問題，因此選擇正確的語言來執行工作可能比嘗試將所有面向都塞進單一語言中更有生產力。

在過去幾年中，對新語言（尤其是函數式語言）的興趣激增，我經常很想花點時間深入研究 Clojure、Scala、Erlang 或類似的語言。但我的時間有限，我更優先考慮另一個更重要的轉變，也就是 DatabaseThaw。第一批客戶和其他聯繫人的訊息已經傳來，前景令人興奮。我可以自信地說，如果你正在啟動一個新的策略性企業應用程式，你就不應該再假設你的持存應該是關聯式的。關聯式選項可能是正確的選項 - 但你應該認真考慮其他替代方案。

模組化資訊豐富程式的最常見方法之一是將其分為三個廣泛的層級：簡報 (UI)、領域邏輯 (又稱業務邏輯) 和資料存取。因此，你經常會看到 Web 應用程式分為了解決 HTTP 要求和呈現 HTML 的 Web 層級、包含驗證和計算的業務邏輯層級，以及整理如何在資料庫或遠端服務中管理持續性資料的資料存取層級。

大多數人最熟悉的關聯式資料模型，是透過關聯式資料庫和 SQL 語言。一般來說，我們將資料庫視為一組表格，每一列都包含資料。我們可以用各種方式操作這些表格來執行查詢，每個查詢都會產生另一個表格。與 網路資料模型 相比，表格之間沒有明確的指標，連結是透過共用值在連結表格中建立的（儘管使用替代鍵表示在實務上您有指標）。

大多數 企業應用程式 會使用資料庫儲存持續性資料。此資料庫支援應用程式狀態的運作更新，以及用於決策支援和分析的各種報表。然而，運作需求和報表需求通常大不相同，對架構和資料存取模式有不同的需求。發生這種情況時，通常明智的做法是將報表需求分隔到報表資料庫中，該資料庫會複製必要的運作資料，但以不同的架構表示。

許多程式需要使用建立和維護成本昂貴的資源。資料庫連線和執行緒就是範例。資源池提供管理這些資源的良好方法。

幾年前，我與在 eBay 工作的幾位朋友聊天。了解人們在高流量網站上使用的技術總是很有趣，但最有趣的趣聞之一可能是 eBay 幾乎從不使用資料庫交易。

軟體系統中常見的功能是允許使用者在資料結構中定義自己的欄位。考慮一個通訊錄，有很多東西您可能想要新增。隨著每天出現新的社群網路，使用者可能想要為其聯絡人新增 Bunglr ID 的新欄位。

goto（以前稱為 JAOO）一直是我最喜歡的會議。多年來，他們在維持高標準的內容的同時，還結合了高效且友好的組織，做得非常出色。因此，儘管我過度參加會議通常會導致會議恐懼症，但當我前往前往 Aarhus 的有些複雜的行程時，我仍然感到一種愉快的期待。