云南网站开发旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8b890668b9ce.html
📄
云南网站开发旧系统字段无法完整迁入时怎样决定保留项
先判断字段在新系统里是否还有"业务承接者"：如果某个字段的数据仍会被查询、展示、导出或参与后续流程，它就应该保留；如果它只是旧流程的中间产物、无人再读，就不该为了"迁得完整"而硬塞进新结构。决定保留项的关键不是字段数量，而是每个字段背后有没有明确的使用场景和责任人。
条件一：字段仍被业务使用时，优先保留并做映射
当旧字段对应的信息仍会出现在日常操作中，例如客户备注、历史订单状态、地区归属，保留的判断依据是"谁在什么动作里会用到它"。这时不要直接把旧字段名照搬进新表，而是先确认它在云南网站开发的新数据模型里对应哪个业务对象。
实施动作可以分三步：先列出该字段的读取场景，再确认新系统是否有等价结构，最后决定是合并、拆分还是新增。比如旧系统用"联系人备注"一个字段同时存电话和偏好，新系统已有独立电话字段，就应把偏好部分迁到备注，而不是整段塞进电话字段。做完这一步，后续的查询和导出才不会出现一条记录里混着两类信息的情况。
例外是：字段虽被使用，但使用频率极低且只服务于即将下线的旧流程。此时可以只做一次性归档导出，不进入新系统主表，避免为短期需求污染长期结构。
条件二：字段不再被业务读取时，用"证据"而非"感觉"决定丢弃
判断一个字段是否真的没人用，不能只看自己印象。可区分的证据包括：旧系统的查询日志里该字段是否出现在筛选条件中、导出模板里是否包含它、前台页面是否渲染它、下游对接是否读取它。如果这几处都查不到引用，丢弃的把握就比较大。
但要注意，请求量或读取量归零不能单独证明处理正确。它还可能是因为旧系统入口已经关闭、统计只覆盖了部分模块、或者数据被缓存在别处。更稳妥的做法是：先冻结该字段的写入，观察一个业务周期内是否有人反馈缺失，再决定是否彻底删除。这个动作的结果会直接影响下一步——如果无人反馈，就可以从迁移清单中移除；如果有人反馈，说明存在未被记录的隐性使用，需要重新评估。
迁移前先做字段分类，避免逐条争论
与其对每个字段单独开会讨论，不如先按用途分组，再对整组做决定。常见分组方式如下：
- 身份与联系类：姓名、电话、地址等，通常必须保留，但要检查是否有重复或冲突。
- 流程状态类：订单阶段、审批结果等，保留价值取决于新流程是否沿用同一套状态。
- 自由文本类：备注、说明、内部记录，最容易堆积无用内容，建议抽样查看后再定。
- 系统生成类：创建时间、操作人、旧编号，多数需要保留用于追溯，但不必全部展示。
分组之后，每组指定一个业务负责人确认，比逐字段争论更快，也更容易留下可复查的依据。
假设例子：一个字段的去留怎样影响后续动作
假设旧系统有一个"客户来源渠道"字段，新系统没有对应结构。先查证据：导出报表里是否按它分组、前台是否展示、销售是否在跟进时参考。如果报表仍在用，就应在新系统里保留为可选字段并做映射；如果只有历史报表用过、当前无人引用，就可以只归档不迁入。
这个判断的结果会改变下一步：保留时，需要为新字段补上录入入口和校验规则，否则数据会逐渐空缺；丢弃时，需要在归档说明里写清该字段的去向，方便以后有人查旧数据时知道去哪里找。两种选择都成立，区别只在于是否有持续的使用需求。
决定保留项时要写下的三件事
无论最终保留还是丢弃，都建议记录三点：该字段的判断依据、负责确认的人、以及后续如需恢复时的取数位置。这样做的目的不是增加文档负担，而是让下一次结构变动时，不必重新猜测当初为什么这样处理。字段迁移从来不是"越全越好"，而是让留下来的每一项都能被解释清楚。
