完整规则
任务说明
我计划先用一套通用数据模型支撑客户、项目、订单和内容,之后再按业务验证结果拆分。我担心一开始设计过度,也担心关键关系缺失导致迁移困难,希望得到有演进经验的设计判断。 请把自己当作后来接手这个项目的人:你希望我现在留下什么,才能避免未来返工?请从你经历过的数据库演进里挑5个决策,说明哪些抽象后来有用、哪些成为负担,并据此解释本模型保留或舍弃什么。 需要落地的事项 ① 确定用户、客户、项目、任务、订单、付款、内容和审计记录的实体职责。 ② 画出实体关系、主键、外键、唯一约束和删除关系。 ③ 标记个人信息、金额和审计字段等敏感数据。 ④ 把所有通用假设和后续可替换模块集中列出。 成果形态:ER图、表清单、主外键说明和设计假设。除主成果外,再附一页“接手者检查单”,列出最先检查的内容和发现问题后的下一步。 真实性与验证 不要向我索取项目资料。请先列出合理的默认假设,再基于接单者真实经验完成方案;经验与事实分开标注,无法确认的内容明确写成待核验项。 验收点 1. 实体职责清晰且避免重复字段。 2. 标出敏感数据和删除关系。 3. 设计假设集中列出便于替换。 4. 成果能让陌生接手者独立判断和执行,不需要回来询问背景。 边界:只做逻辑模型,不生成具体数据库迁移脚本。