马鞍山建站旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e3d70faa27bb.html
📄
马鞍山建站旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“旧系统里有什么”决定保留项，而要按“新站上线后，哪些字段仍会驱动一个具体业务动作”来决定。做法是拿一张现有页面或一条资料记录，把每个字段标注为“上线后必须可读、必须可写、只需留档”三类；只有前两类进入新结构，第三类转成附件或归档表。这个判断先于选CMS、写迁移脚本和做页面模板。
先判断变化前提：业务动作变没变
字段能不能迁，不取决于旧数据库有多少列，而取决于关键前提是否变化。常见的变化有三种：报价方式从人工改为在线计算；客户资料从销售个人维护改为多角色共享；产品参数从文字描述改为可筛选属性。前提变了，旧字段的保留价值就会重排。
可以用两个选择成立的条件来区分：
- 保留原字段结构：前提是业务动作没变，只是换展示层。例如旧站的产品型号、规格、适配机型仍按同样方式被查询和引用，字段名可以不同，但含义和取值规则要原样保留。
- 重构字段：前提是业务动作已变。例如旧站把“价格”写成一段自由文本，新站要按区间筛选，就必须拆成数值、币种、是否含税、生效日期。此时保留旧文本字段只会让新功能无法落地。
判断时不要问“这个字段以后会不会有用”，而要问“如果它缺失，哪个页面或哪个业务动作会失败”。答不出具体动作的字段，先不进主表。
把一条旧记录拆成三类字段
拿你手上最复杂的一条旧记录来试，不要拿最简单的。假设某条产品资料包含：产品编号、名称、分类、参数文本、价格说明、联系人、联系电话、图片路径、备注、创建时间。可以这样分：
- 必须可读：上线后用户或内部人员要看到，例如名称、分类、参数、图片。这类字段进入新站主表或详情模板。
- 必须可写：上线后还要继续新增、修改、审核，例如产品编号、分类、参数、图片、备注。这类字段除了可读，还要确认新后台是否有对应录入项和校验规则。
- 只需留档：上线后不再参与页面展示和日常操作，但可能被审计、对账或客服追溯，例如旧联系人、旧电话、创建时间。这类不要硬塞进主表，转成归档表或附件字段，并保留原记录ID。
如果某个字段既不属于可读，也不属于可写，还不能说明留档用途，就暂时不迁。暂时不迁不等于删除，旧库先冻结只读，等新站运行一段时间后再决定是否清理。
用短例子验证保留项是否成立
下面是一个假设例子，用来演示比较方法，不是真实项目结果。假设旧站有“价格说明”字段，取值是“面议”“含税价 1200 元起”“需根据数量确认”。新站要做一个按价格区间筛选的列表页。若直接保留原字段：
- 列表页无法可靠排序，因为“面议”和“1200”不是同一类型。
- 筛选条件只能做成关键词搜索，结果会混入无关记录。
- 后续运营每次改价都要同时改文本和筛选条件，容易不一致。
更可行的处理是拆成四个字段：price_mode（面议/固定/区间）、price_min、price_max、price_note。旧文本整体保留到price_note作为留档，新列表页只读前三个字段。动作是：先在新结构里建这四个字段，再写一条迁移规则，把能解析的旧值填入数值字段，不能解析的统一标为“面议”。这个动作的结果会直接影响下一步——如果解析失败率很高，说明旧数据本身不适合做筛选，应先改业务录入规则，而不是继续写更复杂的解析脚本。
决定保留项后，先冻结再迁移
字段清单确定后，不要立刻全量导入。先做三件事：
- 冻结旧库写入：把旧系统改为只读，避免迁移期间新旧数据同时变化。若业务不能停，至少记录冻结时间点，后续差异单独补录。
- 抽样比对：从每条业务线各抽若干条记录，按新字段规则手工填一遍，再和迁移脚本结果比对。重点看空值、异常值、超长文本和特殊符号。
- 保留回退路径：旧库和旧附件不要在同一时间删除。新站上线后，若发现某个字段缺失导致业务动作失败，可以按原记录ID回查补迁。
如果抽样时发现大量记录无法归入已定字段，说明保留项划分过粗，应回到上一步重新区分“可读、可写、留档”，而不是在导入阶段临时加字段。临时加字段会让新站结构迅速膨胀，后续模板、筛选和权限都会变复杂。
哪些字段可以明确放弃迁入
以下情况通常可以不进入新站主结构，但要有替代处理：
- 重复字段：同一含义在旧库有多个列，例如“电话”“联系电话”“手机号”，先确认哪个是当前有效来源，其余转留档。
- 废弃选项：旧分类或旧标签已不再使用，且没有页面引用。可以保留在归档表，不进入新站分类树。
- 纯展示残留：旧模板里的装饰性文字、过期活动说明、已下线的客服入口。若没有业务动作依赖，不迁。
- 无法解析的自由文本：若一段文本既不能拆成结构化字段，也没有检索需求，整体放入备注或附件，不强行拆解。
放弃迁入的前提是：你能说清它不再驱动任何页面、筛选、通知或对账动作。说不清就先留档，不要直接删除。
把决定写成可执行清单
最后，把结论落成一张处理表，每行一个旧字段，列至少包含：旧字段名、含义、新字段名、类型、是否必填、是否可读、是否可写、留档方式、迁移规则、验证样例。填完后先让实际使用这些数据的人确认，再开始写导入程序。这样做的结果是：迁移脚本只处理已确认的字段，页面模板只依赖已确认的结构，后续出现缺失时也能快速定位是“当初决定不迁”还是“迁移遗漏”。
如果旧系统字段数量很多，优先处理会影响下单、报价、客服查询和内容发布的那几条记录，其余字段按同一方法分批判断。每批完成后都用一条真实业务动作验证，确认新结构能支撑该动作，再进入下一批。
