在过去十年中，我们开发并完善了许多技术，允许数据库设计随着应用程序的开发而演进。这对敏捷方法论来说是非常重要的能力。这些技术依赖于将持续集成和自动化重构应用于数据库开发，以及数据库管理员和应用程序开发人员之间的密切协作。这些技术适用于预生产和已发布的系统，也适用于全新项目和遗留系统。

我和我的同事 Badri 就六边形架构及其在 Rails 应用程序中的作用进行了一次对话，这里有两个视频。在第一个视频中，我们讨论了六边形架构的含义，以及这如何导致在持久化框架中选择 Active Record 和 Data Mapper 模式。在第二个视频中，我们更广泛地讨论了 Rails 在应用程序中应该扮演的架构角色——你应该把它看作一个平台，还是一套组件。

我们在 2012 年伦敦 QCon 大会上的主题演讲探讨了数据在我们生活中所扮演的角色（它不仅仅是变得越来越大）。我们首先来看看数据世界是如何变化的：它在增长，变得更加分散和互联。然后，我们来看看行业的反应：NoSQL 的兴起、向服务集成的转变、事件溯源的出现、云的影响以及可视化在分析中的作用越来越大。我们快速地看一下数据现在是如何被使用的，Rebecca 特别强调了发展中国家的数据。最后，我们思考了所有这一切对我们作为软件专业人员的个人责任意味着什么。

在 奥尔胡斯 Goto 大会 上，我们有一个关于 NoSQL 实践经验的专题讨论。我被邀请做一个开场演讲，解释 NoSQL 数据存储的基本原理。我谈到了 NoSQL 的起源、NoSQL 数据模型的形式、许多 NoSQL 数据库如何考虑一致性问题，以及多语言持久化的重要性。

近年来，关于无模式数据的优势的讨论越来越多。无模式是人们对 NoSQL 数据库 感兴趣的主要原因之一。但是，无模式涉及许多微妙之处，无论是数据库还是内存数据结构。这些微妙之处既体现在无模式的含义上，也体现在使用无模式方法的优缺点上。

Pramod Sadalge 领导了敏捷数据库技术的开发，我们现在在 Thoughtworks 习惯性地使用这些技术。SE Radio 采访了我们如何使用这些技术与使用数据库的应用程序一起迭代地演进数据库的设计。我们讨论了如何将数据库纳入持续集成系统，如何通过可重复的脚本迁移进行数据库更改，以及数据库重构是如何工作的。

这是一张关于企业数据存储未来的信息卡，主要面向参与应用程序开发管理的人员。解释了为什么关系数据库一直占据主导地位，为什么 NoSQL 正在挑战这一假设，并概述了多语言持久化的未来，即根据不同的需求，应用程序将使用多种数据存储技术。

在过去二十年中，我们看到面向数据库的软件开发人员和内存应用程序软件开发人员之间的差距越来越大。这导致了许多关于如何使用 SQL 和存储过程等数据库特性的争论。在本文中，我将探讨是将业务逻辑放在 SQL 查询中还是放在内存代码中的问题，主要考虑基于一个简单但丰富的 SQL 查询示例的性能和可维护性。

当我们编写 《NoSQL 精粹》 时，首先想到的主题之一是 NoSQL 数据库使用的数据模型与关系模型不同。我查阅的大多数资料都提到了至少四组数据模型：键值、文档、列族和图。观察这份清单，前三者之间有一个很大的相似之处——它们都有一个基本存储单元，它是一个由密切相关的数据组成的丰富结构：对于键值存储，它是值；对于文档存储，它是文档；对于列族存储，它是列族。用领域驱动设计（DDD）的术语来说，这组数据是一个 DDD 聚合。

我使用术语“应用程序数据库”来指代由单个应用程序控制和访问的数据库（与 集成数据库 相对）。由于只有一个应用程序访问数据库，因此可以专门定义数据库，以便于满足该应用程序的需求。这将导致一个更具体的模式，该模式通常更容易理解，并且通常比 集成数据库 的模式简单。

数据湖是近十年来出现的一个术语，用于描述 大数据 领域中数据分析管道的一个重要组成部分。其理念是为组织中任何可能需要分析的原始数据提供一个单一的存储库。通常，人们使用 Hadoop 来处理数据湖中的数据，但这个概念比 Hadoop 更广泛。

我早期最喜欢的书之一是 Tsichritzis 和 Lochovsky 合著的《数据模型》。这本书讨论了思考数据的不同模型，特别是当时讨论最多的三种模型：关系数据模型、层次数据模型 和 网络数据模型。

当我谈到数据库以及它们与应用程序的关系时，我发现区分两种数据库风格很有用：应用程序数据库 和 集成数据库。两者的区别在于数据库是否在单个 应用程序边界 内被控制和封装。

几年前，我听到编程语言界的人在谈论 Java 造成的语言“核冬天”。他们觉得每个人都如此依赖 Java 的计算模型（当时 C# 被认为只不过是抄袭），以至于编程语言的创造力已经消失殆尽。这种感觉现在正在消退，但也许更重要的是，数据库思维的解冻可能正在开始——这是一个更长、更深的解冻过程。

Datensparsamkeit 是一个德语单词，很难准确地翻译成英语。这是一种关于我们如何捕获和存储数据的态度，即我们应该只处理我们真正需要的数据。

层次数据模型以层次结构或树结构的形式组织数据。早期的数据库和编程数据结构通常使用层次模型，但这些模型已经失宠。在数据库领域，关系数据模型 占据了主导地位，而在大多数内存编程中，网络数据模型 占据了主导地位。这是因为层次结构虽然是一种简单的组织工具，但随着数据变得越来越复杂，它就会崩溃。

内存数据库是一种完全在主内存中运行的数据库，不接触磁盘。它们通常作为嵌入式数据库运行：在进程启动时创建，嵌入在该进程中运行，并在进程结束时销毁。

与任何行业一样，软件开发也有一些经常被遗忘的活动，这些活动通常被忽视，但在错误的时间点却会反咬一口。数据迁移就是其中之一。

集成数据库是充当多个应用程序的数据存储的数据库，因此可以跨这些应用程序集成数据（与 应用程序数据库 相对）。

当人们启动一个企业应用程序时，最早的问题之一就是“我们如何与数据库对话”。如今，他们可能会问一个稍微不同的问题：“我们应该使用哪种数据库——关系数据库还是这些 NoSQL 数据库中的一种？”但还有另一个问题需要考虑：“我们是否应该使用数据库？”

网络数据模型将数据结构化为记录类型，并使用指针链接来实现在一条记录和另一条记录之间导航。因此，要查询网络数据模型，你需要从一条记录开始，并围绕指针引用移动。

在许多组织中，任何持久性数据都应该存储在由中央数据库管理组管理的关系数据库中。进行这种集中控制的原因有很多，通常集中在使用集成数据库。中央数据组担心的是防止格式错误的数据、可能降低重要共享资源速度的查询以及整个企业中不一致的数据模型。

这些目标可能是值得的，但其后果之一是存储数据需要相当繁琐的流程。我经常听到人们抱怨说，仅仅为了在数据库中添加一列，变更单就要花上几周的时间。对于习惯于短周期演进式设计的现代应用程序开发人员来说，这样的流程太慢了，更不用说太烦人了。

因此，应用程序开发团队告诉我，他们使用NoSQL 数据库来绕过 DBA。他们在这种情况下使用的是“仅仅是数据存储”，而不是“合适的数据库”，这很有帮助。这样一来，DBA 就可以被排除在外，他们通常不知道也不关心。

我们一开始着手编写NoSQL 精粹就面临着一个棘手的难题——我们到底要写些什么？NoSQL 数据库究竟是什么？这个概念没有明确的定义，没有商标，没有标准组织，甚至没有宣言。

几个月前，我在伦敦参加 QCon 大会时，似乎每场演讲都包含了一些对对象/关系映射 (ORM) 工具的尖刻评论。我想我应该更仔细地阅读发送给演讲者的会议邮件，毫无疑问，邮件里肯定有什么东西告诉我们所有人，每 45 分钟至少要对 ORM 表示一次蔑视。但正如你所知，我想稍微反驳一下这种对 ORM 的厌恶——因为我认为很多厌恶是没有根据的。

2006 年，我的同事 Neal Ford 首次提出了多语言编程一词，以表达应用程序应该用多种语言编写的想法，以便利用不同语言适合解决不同问题的优势。复杂的应用程序结合了不同类型的问题，因此为工作选择合适的语言可能比试图将所有方面都纳入一种语言更有效率。

在过去几年中，人们对新语言，尤其是函数式语言的兴趣激增，我经常忍不住想花些时间研究一下 Clojure、Scala、Erlang 等语言。但我的时间有限，我正在优先考虑另一个更重要的转变，那就是数据库解冻。第一批迹象已经从客户和其他联系人那里传来，前景十分诱人。我可以自信地说，如果你要开始开发一个新的战略性企业应用程序，就不应该再假设你的持久化应该是关系型的。关系型数据库可能是正确的选择——但你应该认真考虑其他选择。

对信息密集型程序进行模块化的最常见方法之一是将其分为三大层：表示层（UI）、域逻辑层（又称业务逻辑层）和数据访问层。因此，你经常会看到 Web 应用程序被分为 Web 层、业务逻辑层和数据访问层，其中 Web 层负责处理 HTTP 请求和渲染 HTML，业务逻辑层包含验证和计算，数据访问层负责理如何在数据库或远程服务中管理持久性数据。

大多数人都是通过关系数据库和 SQL 语言了解关系数据模型的。通俗地说，我们认为数据库是一组表，每个表都包含数据。我们可以用各种方法操作这些表来进行查询，每个查询都会生成另一个表。与网络数据模型不同，表之间没有显式指针，链接是通过联接表上的公共值建立的（尽管使用代理键意味着你在实践中拥有指针）。

大多数企业应用程序都使用数据库来存储持久性数据。该数据库支持对应用程序状态进行操作更新，还支持用于决策支持和分析的各种报表。然而，操作需求和报表需求通常截然不同——对模式的要求不同，数据访问模式也不同。当出现这种情况时，通常明智的做法是将报表需求分离到一个报表数据库中，该数据库获取基本操作数据的副本，但使用不同的模式来表示它。

许多程序都需要使用创建和维护成本高昂的资源。数据库连接和线程就是这样的例子。资源池提供了一种管理这些资源的好方法。

几年前，我和在 eBay 工作的几个朋友聊天。了解人们在高流量网站上使用的技术总是很有趣，但也许最有趣的一点是，eBay 几乎从不使用数据库事务。

软件系统中的一项常见功能是允许用户在数据结构中定义自己的字段。以地址簿为例——你可能想添加很多东西。随着每天都有新的社交网络涌现，用户可能希望为他们的联系人添加一个 Bunglr ID 的新字段。

goto（前身为 JAOO）一直是我最喜欢的会议之一。多年来，他们出色地保持了高质量的内容以及高效友好的组织。因此，虽然我过度参加会议通常会导致会议恐惧症，但在前往奥胡斯进行 somewhat 复杂的旅程时，我仍然感到一种愉快的期待。