字数 9734，阅读大约需 49 分钟

第25讲："智慧邻里"的"地基"（数据工程）

【老孙开篇寄语】

同学们，欢迎来到“工程篇”的第五站。

在过去的几讲中，我们，为“智慧邻里”这座“软件城市”，规划了“功能分区”（用例图），设计了“交通干道”（活动图），搭建了“建筑骨架”（类图），并彩排了“市民的活动”（顺序图）。

今天，我们要来关注，这座城市，最“底层、最核心、最不可或-缺”的基础设施——供水系统。

在软件世界里，“水”，就是“数据（Data）”。

数据，是现代IT系统的“血液”和“石油”。我们之前，所做的一切“功能”和“流程”，其本质，都是在“处理”和“流转”数据。一个没有“数据”的系统，就像一座“没有市民的空城”，毫无价值。

数据工程（Data Engineering），就是一门，关于“如何，为一座城市，设计、建造、和维护一套‘高效、安全、纯净’的供水系统”的科学。

在这一讲中，我们将扮演“数据总工程师”的角色。

• • 我们将从“哲学”的层面，去探讨“数据、信息、知识、智慧”之间的“升华之路”，理解我们，做数据工程的“终极目的”。
• • 我们将穿越“历史”，去亲历一场“数据库的战争”，理解“SQL”与“NoSQL”这两大“门派”，各自的“武功”和“适用场景”。
• • 我们将深入“实践”，去系统地，学习“数据建模”的“三重境界”，并亲手，为“智慧邻里”项目，绘制出它的“数据蓝图”——E-R图。
• • 最后，我们将挑战，整个数据库理论中，最“烧脑”，但也最“精髓”的部分——数据库范式（Normalization），去学会，如何，设计出“没有冗余、不会出错”的“完美”数据结构。

这是一堂“奠定根基”的课。学好它，你将掌握，构建一个“健壮、可靠、可扩展”的软件系统的“底层密码”。

第一章：上节回顾与热身

1.1 上节核心回顾

在铺设“数据管道”之前，我们先快速回顾一下，上一讲，我们作为“建筑结构师”，所掌握的两大“微观设计工具”：

1. 1. 工具一：类图——绘制“静态的解剖图”
• • 我们深刻地认识到，类图，是系统的“静态户籍库”。它，通过“类”和“六大关系”，清晰地，描绘了系统的“组成结构”和“基因图谱”。
• • 高项认知： 一个“健康”的系统，其类图，必然“疏朗有致”，充满了“弱关联”。而一个“腐烂”的系统，其类图，一定是“蛛网密布”的。看懂类图的“耦合度”，是项目经理，识别“技术债”的“X光眼”。
2. 2. 工具二：顺序图——描绘“动态的心电图”
• • 我们学习了，如何，用“顺序图”，特别是，利用“生命线、消息、和高级片段”，来像“电影分镜”一样，清晰地，描绘一个“功能”背后的“对象交互”过程。
• • 高项认知： 类图，回答了“有什么”；顺序图，回答了“怎么动”。只有，将“静态结构”与“动态行为”，结合起来，我们，才能，完整地，理解一个“设计”。

1.2 上节课后作业精讲

上一讲的第三个作业，是一个“极具实战价值”的“真实两难”问题。它，要求你，戴上“项目经理”的帽子，去“仲裁”一场，关于“技术设计”的“路线之争”。

场景复盘：
在“在线报修”功能的设计评审会上，两位核心程序员，小张和小王，对“工单（RepairOrder）”的处理流程，提出了两种不同的设计方案，并为此，争论不休。

• • 小张（方案A - 简单设计）： 他主张，就在RepairOrder表里，增加一个status字段（比如，1-待处理, 2-处理中, 3-已完成）。
• • 理由： “快！ 今天，就能写完！符合‘敏捷开发、快速迭代’的原则！”
• • 理由： “长远看，扩展性更强，而且，保留了完整的业务数据，未来，可以做数据分析！”

一个“不成熟”的PM，此时，可能会，无法理解他们的“争论点”，然后，简单地，说一句：“你们，技术上，看着办吧”，或者，更糟糕的，“谁快，就听谁的！”
而一个“成熟”的PM，他，能听懂“技术语言背后的‘商业逻辑’”，并，能从“项目的整体利益和长远价值”出发，来做出“明智的”决策。

现在，看老孙，如何，主持这场“设计方案决策会”。

【“设计方案决策会”全景推演】

(会议室里，小张和小王，都，看着你，等待你的“最终审判”。)

“首先，我，要分别，感谢小张和小王。”

“小张，我，非常欣赏你，对‘项目进度’的‘责任心’。你的方案，体现了‘KISS（Keep It Simple, Stupid）’原则和‘YAGNI（You Ain't Gonna Need It）’原则，这，在很多场景下，都是“完全正确”的。用‘最简单’的方案，去‘最快速’地，响应‘当前’的需求，这是‘敏捷’的精髓。”

“同时，小王，我，也，非常欣赏你，对‘软件质量’和‘长期价值’的‘追求’。你的方案，体现了‘设计模式’的思想，考虑到了，未来的‘可扩展性’和‘可维护性’。这，是一个‘优秀架构师’的‘潜质’。”

“他们两个，都没有‘错’。他们，只是，站在了‘不同的价值尺度’上，在为项目的‘利益’，而争论。一个，代表了‘短期利益（速度）’；另一个，代表了‘长期利益（质量）’。”

“那么，作为PM，我，该如何决策呢？我的决策依据，不是‘技术本身’，而是‘需求，特别是，那些，隐藏在功能背后的‘非功能性需求’和‘未来的可能性’。”

“所以，我要问几个问题：”

“第一个问题，问产品经理：在我们的《产品路线图（Roadmap）》中，我们，是否，规划了，在未来（比如，三个月后），要上线一个‘物业服务效率分析’的报表功能？”

• • 产品经理： “是的，老孙。我们，计划，在下个季度，要向‘管理层’，提供一个数据看板，其中，最重要的一个指标，就是‘平均报修响应时长’和‘平均维修完成时长’。”
• • 你的分析： “好。那么，这个需求，就，对我们的‘数据结构’，提出了一个‘明确的要求’。我们，必须，能‘记录下，每一次状态变更的‘时间戳’’。小张的方案A，无法，支撑这个‘未来的’需求。而小王的方案B，则‘天然’，就支持。”

“第二个问题，问业务顾问：我们的‘报修流程’，在未来，有没有可能，变得‘更复杂’？”

• • 业务顾问： “完全可能！比如，我们，正在考虑，未来，要引入‘配件申请’流程。也就是说，工单，可能会，进入一个‘等待配件’的状态。还可能，要有‘用户确认’环节，工单，会进入‘等待用户验收’的状态。”
• • 你的分析： “好。这个需求，又，对我们的‘代码结构’，提出了一个‘明确的要求’。如果，我们，用小张的方案A，那么，每一次，增加一个‘新状态’，我们的代码里，就要，增加一堆if...else...的判断，很快，代码，就会变得‘难以维护’。而小王的方案B，采用‘状态模式’，每增加一个新状态，我们，只需要，增加一个‘新的状态类’就行了，对‘原有代码’，几乎，没有‘侵入’。这，就是‘开闭原则（Open-Closed Principle）’的体现。”

“第三个问题，问小张和小王：方案B，比方案A，大概，会多花‘多长时间’的开发工作量？”

• • 小张和小王（讨论后）： “大概，会多花‘2-3个’人天。”

【最终的决策】
“好，感谢各位。现在，我的决策，已经非常清晰了。”

“我宣布，我们，采用‘方案B（状态模式设计）’。”