流程图告诉你系统做什么,数据模型告诉你系统记得什么。在《搭建Twitter克隆》课程的第二课里,作者抛出了一个反直觉的观点:先别急着画流程图——因为不知道要存什么数据的流程图,会在关键地方模糊得恰到好处。
以"发布一条消息"为例。流程图上可以简单写一个"保存消息"的方框,但真到实现时,问题接踵而至:保存什么?文本?作者?时间戳?作者身份从哪来——是临时输入的名字,还是指向已存账户的引用?如果同一个人发了两条消息,系统怎么知道它们属于同一个作者?
![]()
这些答案藏在数据模型里:系统长期记忆的正式描述。没有它,每个请求都从零开始;有了它,今天发的消息明天还在,发帖人也能被找到。
作者从三个用例中提炼出线索,命名系统必须追踪的实体,定义它们的字段和关系,最终翻译成真实的MySQL表结构。但这里有个关键决策:数据该放在一个数据库还是多个?
Bird选择了两个数据库——这个设计在课程后续展开。当一条消息被定义为包含id、不超过280字符的content字段、以及指向特定用户的author_id时,"保存消息"就不再是占位符,而是可执行的指令。功能模块有了清晰的契约,时序图也能明确组件间传递的内容。
数据模型是蓝图之下的蓝图。它不提供视觉冲击力,却决定了系统能记住什么、如何记住——以及记住多久。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.