8.3 替代方案与未来演进
8.3 替代方案与未来演进
本节摘要：成熟的接单人不对工具动感情。Access 至今仍随 Microsoft 365 发布并获官方长期支持，但微软的创新重心已明确转向 Power Platform；对你的系统而言，真正的决策不是"Access 好不好"，而是"我的业务是否触碰了它结构上的天花板"。本节给出触发信号清单与四条路线的对比，帮你把这个问题变成一道可以冷静计算的题。
聊到 Access 的未来，网上常见两种极端论调：一种说"早过时了赶紧扔"，另一种说"永远够用别折腾"。做过几年交付的人明白，两者都错了——错在把一个"时机问题"硬答成了"立场问题"。这一节的任务是把答案变成可判断的条件。
先看信号：什么时候该认真讨论换马
不必天天焦虑，但以下四个信号出现任何一个，就该坐下来做正式评估：
- 并发冲突从偶发变常态。第 7 章的调优手段用尽之后，记录锁定报错仍然每周出现，说明业务并发的真实规模已经越过了文件型引擎的能力圈；
- 单库体积逼近警戒线。归档做了一轮又很快涨回来，数据增长速度肉眼可见地追着上限跑；
- 需求开始要求"随时随地"。管理层要手机审批、外勤要异地录单、客户要看在线报表——Web 化诉求是桌面架构的无解之题；
- 合规门槛抬高。审计要求字段级权限、要求操作留痕不可篡改，这类需求文件级安全给不出。
华彩项目第三年检查了一遍：四条一条都没触发（并发三人、文件 400MB、无移动需求、审计仅要求月度报表），结论是继续安心服役，每年例行复查一次。评估本身半小时，买到的是一整年的踏实。
四条路线各自的模样
真到了要动的时候，路其实只有四条，没有第五条秘密通道：
| 路线 | 一句话概括 | 迁移成本 | 保留哪些资产 | 适用时机 |
|---|---|---|---|---|
| 原地打磨 | 拆分、链接、归档三板斧再走一遍 | 极低 | 全部 | 信号尚未触发 |
| 后端升迁 | 数据搬去 SQL Server，前端不变 | 中 | 界面、查询、全部 VBA 逻辑 | 信号一或二触发 |
| 低代码重构 | 需求重新实现为 Power Apps 应用 | 高 | 数据模型设计经验 | 信号三或四触发 |
| 自研接管 | Web 技术栈重写 | 最高 | 业务知识本身 | 组织有研发团队且值得 |
重点展开中间那条，因为它被严重低估。后端升迁在工程上相当平缓：官方历来提供升迁向导类工具，把表结构与数据搬到 SQL Server 之后，前端只需在链接表管理器里重新指向新后端，绝大多数窗体报表当晚就能照常工作。真正的工作量在细节：DAO 写法在跨网络环境下的性能习惯要调整（复杂汇总下推给服务器视图跑）、索引策略按服务器的规则重建、以及本节的上一章讲过的事务边界变化。华彩-style 的中型台账做这样一次升迁，通常按天计而不是按月计。
图：从信号识别到路线选择的决策路径
微软的真实态度：支持照旧，创新转向
商业判断要有事实依据。可以确认的事实有三件：其一，Access 至今包含在 Microsoft 365 商业版套件中，官方承诺持续提供安全更新；其二，近十多年它的新功能节奏明显放缓，版本更替以兼容性与稳定性维护为主；其三，微软把新一代业务应用的战略押在了 Power Platform 上，市场资源与新特性都在那边。三件事拼起来的图景很清晰：这是一位进入养护期的老将，可靠、便宜、不会再长新本事。
由此推出两条实践准则：第一，存量系统不必恐慌性迁移，官方支持期内它的运行风险低于任何匆忙的重写；第二，新建系统若一开始就带着强烈的云协作基因，那就诚实地承认 Access 不是最佳起点，别为了熟悉而选它。
升迁工地的三个真实细节
既然"后端升迁"是性价比之王，把工地上的真实经验再多给三块砖。
DAO 拿链接表当自家表用会吃亏。 迁移完成后原有的循环遍历代码不改也能跑，但跨网络的往返次数肉眼可见地增加。两种程度的应对：轻症是打开记录集时补上要求行级可靠的选项参数并减少不必要遍历；重症是把逐行计算整段搬进服务器端的视图或查询对象里一次跑完。判断标准只有延迟一个词——十毫秒级的本地调用搬到网络上就要按百毫秒计。
类型映射有雷区。 Access 的自动编号对应 SQL Server 的自增列，逻辑无缝但语义有差（后者重置更麻烦）；日期精度、文本长度上限、布尔值的表达三者各有小动作要核对。升迁向导能处理九成，剩下的一成恰恰都在你最重要的那张流水表上——验收时按字段清单逐一比对展示值。
权限模型顺势升级。 文件时代"能拿到文件就有一切"的逻辑作废，服务器端可以真正按登录账号授权到表和列。迁移是重做安全设计的唯一免票窗口，错过它下次重构就是数年之后的事了。
给犹豫者的三问
还不确定要不要启动评估的团队，请回答这三个问题：现在每晚的备份脚本是否已经完全无人值守？出现写入冲突时的处理流程是否有书面版本？如果把后端换成服务器，谁能在一天之内恢复全部业务？三问全绿说明运维已成熟到可以安全动手术；任何一问答不上来，先回去补第 7 章的课——地基不稳不该加楼。
升迁的成本账单要当面算清
向客户汇报升迁方案时，最忌只报"搬数据很快"。一份负责任的工时估算至少包含五栏：表结构与索引迁移（工具自动化居多）、前端重链接与回归测试（按窗体数量逐个过）、DAO 遍历性能改造（视代码风格可大可小）、权限体系重建（新增项）、以及一段固定长度的双轨并行期——新旧后端各跑两周对数。华彩量级的系统前四栏合计约十个工作日，第五栏占日历时间但几乎不占人力。
预算里还要给"失败退路"留一行：万一服务器环境迟迟批不下来，链接回原 accdb 后端的一小时就能整体撤回。正因为升迁路径进可攻退可守，它才是所有升级讨论里我们的默认起点；激进方案不是不能选，而是要先回答"为什么不选温和的这条"。
低代码浪潮里，你的功夫并没有白费
有意思的是，Power Apps 这类低代码平台的核心工作内容，恰恰是第 2 章练过的那门手艺的延伸：定义实体、理清关系、约束录入口径。平台替你省掉的是窗体拖放和 VBA 编码，但数据建模的功力一分都替代不了——现实中大量低代码项目的失败根源仍是烂表结构。换句话说，即使将来整个行业搬了家，跟着你一起搬走的正是这本书最重的那几章。
华彩五年推演放在这里作为收束示例：第四年若仓库扩张到两个仓，先原地加仓位维度即可；第五年若开了三家分店、十几人同时进出货，后端升迁就该排上日程；至于老板娘念叨的手机查库存，用 Power BI 给她配一块随时刷新的报表就够，犯不着为此重构系统。每一步都踩在信号上，而不是踩在风口上。
本节要点回顾
- 判断去留靠四个硬信号：并发常态冲突、容量逼近上限、移动化诉求、合规抬杠，缺一都不足以立项；
- 路线仅四条，其中"后端升迁、前端保留"是被低估的性价比之王，成本按天计；
- 官方长期支持但创新停摆，存量安心、增量慎选新坑；
- 低代码时代建模手艺依然保值，这正是本书前半部反复操练的东西。
下一节做一个特殊的练习：领一个全新的小委托，把全书八章的手艺当场从头到尾使一遍。