北京
流程图告诉你系统做什么，数据模型告诉你系统记得什么。在《搭建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.
