数据库技术选型决策记录（ADR）实战：关系型、文档型与事件型数据库的对比与选择-开发者社区

【免费下载链接】architecture-decision-record

Architecture decision record (ADR) examples for software planning, IT leadership, and template documentation

项目地址：https://gitcode.com/gh_mirrors/ar/architecture-decision-record

这篇技术指南围绕 architecture-decision-record 仓库中提供的《数据库技术选型》示例（西语原文，英文原文）展开，逐段拆解一份标准 ADR 的写法：如何在"状态—上下文—决策—理由—后果"五段式结构中，完成一次面向可扩展、高性能需求的数据库技术选型，并给出可复制的模板骨架与文件规范。读完本文，你将掌握用 ADR 固化数据库选型决策的完整方法，并能直接在团队中落地使用。

一、文档定位：一份遵循 Nygard 五段式结构的示例 ADR

本仓库（architecture-decision-record）收集了大量架构决策记录（ADR）的模板与示例，其中《数据库技术选型》是"示例（examples）"分类下的一份典型文档，位于locales/es-001/ejemplos/elección-de-una-tecnología-de-base-de-datos/，并在西班牙语示例索引中被归入"ChatGPT 示例"组；其英文原版位于 locales/en-001/examples/choosing-a-database-technology/。

该示例严格遵循由 Michael Nygard 提出的经典 ADR 结构，即"标题、状态、上下文、决策、后果"五段式（西语模板）：

段落	本文示例中的标题	作用
状态	Estado（Status）	记录决策当前的生命周期状态
上下文	Contexto（Context）	说明问题背景、驱动因素与备选空间
决策	Decisión（Decision）	明确陈述最终选择的方向
理由	Justificación（Rationale）	给出选择该方案的原因与权衡
后果	Consecuencias（Consequences）	说明决策带来的收益、成本与后续影响

这份示例的价值在于：它不是空泛的模板占位，而是一份"可以照抄改写"的真实决策文本，展示了如何把数据库领域的三类主流技术放进 ADR 的框架里做结构化比较。

二、状态（Estado）：决策的当前生命周期

示例文档第一部分是：

Estado：Aceptado

"Aceptado"对应英文模板中的 "Accepted"（已接受）。ADR 的状态字段是决策被后续读者（包括未来的开发者、审计者、AI Agent）理解的关键元数据。根据仓库附带的 architecture-decision-record-skill 中的约定，常见状态取值包括：

proposed（提议中）
accepted（已接受/已批准）
rejected（已否决）
deprecated（已弃用）
superseded by <链接>（已被新 ADR 取代）

把状态写成 "Accepted" 意味着：团队已经完成评估并正式采纳该决策，后续代码与设计都应以此为基准；如果将来推翻它，正确做法不是修改原文，而是新建一份 ADR 并把旧记录标记为 "superseded"（详见下文"文件规范与更新"一节）。

三、上下文（Contexto）：三类数据库技术的全景对比

ADR 的 Context 段要回答"我们为什么需要做这个决策"。示例文档给出的背景是：团队正在设计一款新应用，需要以可扩展、高性能的方式存储和检索数据，为此识别出三类常见数据库技术：关系型数据库、文档型数据库、事件型数据库。原文对这三类技术的描述，是整份 ADR 的信息核心，整理如下：

技术类别	数据组织方式	核心特性	适用场景	典型代表
关系型数据库（Relational）	固定 schema 的表（tables with fixed schemas）	强制严格的数据完整性约束（strict data integrity constraints）	复杂数据关系与事务（complex data relationships and transactions）	MySQL、PostgreSQL、Oracle
文档型数据库（Document）	类似 JSON 的文档（JSON-like documents），无 schema	灵活数据模型，天然支持水平扩展（flexible data models, scaling horizontally）	需要模型灵活演进、横向扩容的应用	MongoDB、Couchbase、Amazon DynamoDB
事件型数据库（Event）	一系列事件（a series of events），记录每次数据变更	完整记录变更历史	审计（auditing）、事件溯源（event sourcing）、复杂数据处理	Apache Kafka、Apache Pulsar、AWS Kinesis

这三类技术并非互相排斥，而是解决不同问题的工具：关系型把"数据一致性、关系完整性、事务"放在首位；文档型把"模型灵活性、水平扩展"放在首位；事件型则把"变化本身"作为一等公民来持久化。

仓库中还有与这三类技术呼应的其他示例，可作为对照阅读：

选择关系型的具体决策文本：MySQL 数据库选型示例（考察易用性、社区支持、性能、安全、成本、技术栈兼容性后选择 MySQL）与 PostgreSQL 数据库选型示例（因 JSON 支持、全文检索、空间数据等高级特性而选择 PostgreSQL）；
与"文档型数据库无 schema、JSON 亲和"主题相关的：API 使用 JSON 还是 gRPC 示例；
与"事件型数据库、事件溯源"主题相关的：仓库主 README.md 的 fitness function 部分给出了示例决策 "We use event sourcing for audit requirements"（我们用事件溯源满足审计需求），与本文示例中事件型数据库的定位完全一致。

四、决策（Decisión）：选择文档型数据库

示例文档的决策段落只有一句话，但信息密度很高：

在仔细评估我们应用的需求与约束之后，我们决定使用文档型数据库（document database）。

一个好 ADR 的决策段应当"直接陈述所选方向，而不是含糊其辞"——这正是 writing-guide 中强调的要点（"Decision should state the chosen direction plainly, not hedge"）。同时，本示例也体现了"一份 ADR 只做一个决策"的原则：它只回答"选哪一类数据库"，至于"具体选 MongoDB 还是 DynamoDB"这类下一层问题，留待后续 ADR 处理。

五、理由（Justificación）：四条选型依据逐条拆解

示例文档用四条理由支撑"选择文档型数据库"的决策，这是整份 ADR 中论证最密集的部分，也是评估一份 ADR 是否合格的核心（"Rationale: explain the reasons for the decision — context, pros/cons of the options, feature comparisons, cost/benefit"）。

理由 1：需要能随业务演进的灵活数据模型。文档型数据库以无 schema 格式存储数据，意味着新增字段、调整已有文档结构都无需修改数据库 schema。相比之下，关系型数据库的固定 schema 意味着任何结构变化都要走ALTER TABLE之类的迁移流程，在快速迭代场景下成本较高。这与上文仓库中 API 使用 JSON 示例所体现的"JSON 数据模型亲和性"思路一脉相承。

理由 2：需要水平扩展以支撑大数据量与高流量。文档型数据库内置分片（sharding）与复制（replication）支持，可以把数据分布到多台服务器，从而支撑高读写吞吐。原文特意强调这是"built-in support"（内置支持），即扩展能力是产品第一公民而非事后补丁。这也是文档型数据库相对传统关系型"纵向扩展（升级单机硬件）"路线的主要差异点。

理由 3：需要快速高效的数据检索。文档型数据库提供强大的索引与查询能力（powerful indexing and querying capabilities），能够针对文档内任意字段建立索引并高效查询，满足应用对低延迟数据访问的要求。

理由 4：应用不需要复杂事务与复杂数据关系。这是最体现"权衡思维"的一条：示例团队坦承，关系型数据库在"强制数据完整性约束、处理复杂事务"方面确实出众，但本应用没有这类需求；文档型数据库为当前用例提供的"足够的一致性（consistency）与持久性（durability）保证"已经够用。这种"承认备选方案优点、再说明为何不适合自己"的写法，正是 ADR 与普通技术笔记的本质区别——决策记录的价值不在于"我选了最好的"，而在于"我清楚地知道放弃了什么"。

六、后果（Consecuencias）：决策的收益与代价

示例文档的 Consequences 段落同时承认了好的一面和需要付出的成本：

需要投入学习成本：选定文档型数据库后，团队必须投资学习与理解所选择的具体技术（如 MongoDB 的查询语言、分片运维等）；
需要保证数据模型匹配：必须确保应用的领域数据模型与文档型数据库的文档模型"合拍"（如聚合边界设计、嵌套文档与引用关系的取舍），才能最大化性能与可扩展性；
总体判断：尽管有上述成本，团队仍认为文档型数据库带来的收益超过成本，是最契合应用需求与约束的选择。

对照 writing-guide 的检查清单，这段 Consecuencias 做到了"既写变容易的事，也写变困难的事"（"Cover what becomes easierandwhat becomes harder"）。它还隐含着后续动作：选型确定后，往往还会触发下一层决策（具体产品选型、分片策略、备份方案等），这些都应该成为新的 ADR——"一个 ADR 常常触发更多 ADR"是 ADR 体系中非常常见的现象。

七、实战落地：如何在自己项目中复刻这条决策记录

7.1 文件命名与目录约定

根据仓库 README.md 中的文件命名规范和 ADR skill，建议：

文件名用现在时祈使动词短语，如choose-database.md（与 commit message 风格一致，便于阅读）；
全小写、单词间用短横线分隔；
扩展名用.md；
存放于项目根部的adr/或decisions/目录；若团队已有编号习惯，可加零填充序号前缀，如0007-choose-database.md。

7.2 可直接套用的模板骨架

以 Nygard 五段式为例（完整骨架见 skill 模板参考）：

# 标题 ## 状态 proposed | accepted | rejected | deprecated | superseded 等 ## 上下文 促使本次决策的问题是什么？ ## 决策 我们提议并/或正在执行什么变更？ ## 后果 因为这次变更，什么变得更容易、什么变得更困难？

7.3 状态流转与更新策略

ADR 默认被视为不可变文档（immutable）：不要改写已接受 ADR 的原始内容；当新决策取代旧决策时，正确流程是——新建一份 ADR 描述新决策，把旧 ADR 状态改为Superseded by [新ADR路径]，并在新 ADR 中反向链接Supersedes [旧ADR路径]。若团队偏好"活文档"风格，也可以在原文基础上追加带日期戳的补充说明，注明信息在决策之后到达——两种约定都可以，关键是团队内部保持一致并明确声明采用哪种。

7.4 可选：用 fitness function 让决策可被验证

文档只负责"记录"决策，而 fitness function（决策适应度函数）负责"保证"决策被执行。仓库 README 给出了示例：决策是"我们用事件溯源满足审计需求"，对应 fitness function 是"在持续集成服务器上测试：所有状态变更必须产生事件"。如果你的选型决策涉及可自动校验的约束（例如"所有写入必须经过某层校验"），可以用同样的方式把决策变成可运行、可断言、可治理的检查。