在 goto Aarhus，我們追蹤了一些 NoSQL 的實務經驗。我被要求給一場演講來解釋 NoSQL 資料儲存的基本原則。我談到了 NoSQL 的起源、NoSQL 資料模型的形式、許多 NoSQL 資料庫考量一致性問題的方式，以及多語言持久性的重要性。

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

當我們設計書籍 NoSQL 精華 時，我們在大部分章節的結尾都做了一些重點摘要，作為讀者重新閱讀書籍時的複習。我們將這些重點摘要放在網站上，作為讀者提醒自己這些重點的另一種方式。

goto Aarhus 的其中一場活動讓 NoSQL 供應商有機會討論他們不同的工具。在活動結束時，不同的講者被安排在一個小組中，討論有關 NoSQL 的一些常見問題。雖然我沒有參與這場活動（我的演講 在幾天後），但我參與了小組討論。

我們在 2012 年倫敦 QCon 的主題演講中，探討資料在我們生活中扮演的角色（而且它不只是變得更大而已）。我們從資料世界如何改變開始探討：它不斷成長，變得更分散且更緊密連結。接著我們探討產業的回應：NoSQL 的興起、轉向服務整合、事件來源的出現、雲端運算的影響，以及視覺化扮演更重要角色的新分析。我們快速瀏覽資料現在如何被使用，Rebecca 特別強調開發中國家的資料。最後，我們思考這一切對我們作為軟體專業人員的個人責任有何意義。

一份關於企業資料儲存未來的資訊文件，主要寫給參與應用程式開發管理的人員。說明為什麼關聯式資料庫一直佔據主導地位，為什麼 NoSQL 會挑戰這個假設，並勾勒出多語持久性的未來，其中會根據應用程式的不同需求使用多種資料儲存技術。

在我們處理 Nosql Distilled 時，首先想到的主題之一是 NoSQL 資料庫使用與關聯模型不同的資料模型。我所看過的大部分資料來源至少會提到四組資料模型：鍵值、文件、列族和圖形。檢視此清單，前三者之間有很大的相似性 - 它們都有一個基本的儲存單元，這是一個緊密相關資料的豐富結構：對於鍵值儲存，它是值，對於文件儲存，它是文件，而對於列族儲存，它是列族。在 DDD 術語中，這組資料是 DDD_Aggregate。

幾年前，我聽程式語言人員談論由 Java 造成的語言中的「核子寒冬」。當時的感覺是，每個人都如此趨同於 Java 的運算模型（當時 C# 被視為僅僅是抄襲），以致於程式語言中的創意消失了。這種感覺現在正在減弱，但或許一個更重要的解凍可能正在開始 - 關於資料庫的思考中更長且更深入的凍結。

最近，我看到越來越多人透過伺服器傳遞 JSON 資料結構。JSON 文件可以直接儲存，方法是使用 AggregateOrientedDatabase 或關聯式資料庫中的 序列化 LOB。JSON 文件也可以直接提供給網路瀏覽器，或用於將資料傳輸到伺服器端頁面渲染器。當 JSON 以這種方式使用時，我聽到人們說使用物件導向語言會造成阻礙，因為 JSON 需要轉換成物件，然後才能再次呈現 - 浪費了程式設計的功夫。我同意關於浪費的觀點，但我認為這不是物件的問題，而是未能理解封裝。

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

這些目標可能很值得，但其中一個後果是儲存資料的繁文縟節相當多。我經常聽到關於變更命令的抱怨，這些命令需要數週才能將一欄新增到資料庫中。對於習慣於短週期演化設計的現代應用程式開發人員來說，這種繁文縟節太慢了，更別提太煩人了。

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

我們開始著手撰寫 Nosql Distilled 時，就面臨一個棘手的難題 - 我們在寫什麼？NoSQL 資料庫到底是什麼？沒有強有力的概念定義、沒有商標、沒有標準群組，甚至沒有宣言。

2006 年，我的同事 Neal Ford 創造了 多語程式設計 一詞，以表達應用程式應該用多種語言撰寫的想法，以利用不同的語言適合解決不同問題的事實。複雜的應用程式結合了不同類型的問題，因此選擇適合這項工作的語言可能比嘗試將所有面向都塞進單一語言中更有效率。

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