# 没API的老系统数据怎么取——异构对接的数据库只读路线

## 引言

企业做数据集成，碰到的第一个拦路虎往往不是技术多复杂，而是手里压根没有像样的接口。一套ERP是十几年前上的，原厂早就停维，接口文档跟着离职的开发一起没了；MES是某厂商的封闭产品，开放接口要另外付费；WMS倒是有几个REST，但字段对不上需求。技术决策者面对的现实是：要打通的十几个系统里，能直接拿来用的API可能不到三成。异构系统对接这道关，绕不开"没API怎么办"这个最朴素的难题。

## 一、没API的几种典型情况

情况一：老系统无API。这是最难的一类。企业IT底座里普遍有一两套运行了十年以上的系统，这些系统设计时压根没有API的概念，所有数据交互走数据库直连或者文件导出。要拿数据，真正稳的入口是数据库本身。

情况二：有API但字段不全。某装备制造企业的MES开放了工单查询接口，但只返回工单号、状态、完工数量三个字段，工艺参数、班次、设备这些关键字段没有。接口看似通了，实际能用起来的数据不到业务需要的四成。这种半接口对接往往比无接口更折腾，因为给了希望又满足不了。

情况三：接口要收费或审批周期长。一些商业系统的开放接口是收费模块，或者要走厂商审批，周期两三个月起步。业务侧等不起这种节奏，技术侧又不能绕过厂商乱改系统。异构系统对接在这种场景下，被接口的商业策略卡死了。

向量空间JBoltAI在项目里反复遇到的，正是这三类加在一起的局面——纯无API的占大头，有接口不完整的中等，接口要花钱花时间等审批的也不少。指望靠写接口把所有系统打通，在大多数企业里不现实。

## 二、数据库只读：没API时的务实路线

既然接口这条路走不通，退一步的路线是数据库只读。核心原则就一条：不修改原系统结构，只架在现有系统之上读数据。向量空间JBoltAI做异构对接时把这条原则当成底线——对客户业务系统零侵入，只读不改。

为什么强调只读。老系统最怕被改坏。一套跑了十年的ERP，数据库结构是当年厂商设计的，表之间有隐含的触发器、有存储过程、有历史遗留的脏数据依赖。一旦写操作进去，很可能破坏原系统的数据一致性。只读连接从根上规避这个风险，原系统一行代码、一条记录都不动，只是在旁边读一份。

只读连接的工程做法分几步。第一步拿到数据库的只读账号，权限只给SELECT，不给INSERT、UPDATE、DELETE。第二步对核心业务表做结构分析，搞清楚订单、工单、库存这些核心实存在哪些表、字段含义是什么。第三步建一层只读视图，把原始表的字段翻译成业务可理解的名称，比如把MES里字段名"wo_status=3"翻译成"工单完工"。向量空间JBoltAI在对接某装备制造企业老ERP时，就是用这套只读路线，原系统一行没动，把订单、BOM、库存三张核心表的数据取了出来。

关键工程细节有两个。一个是连接池要单独建，不要复用原系统的连接，避免读操作的负载拖垮生产库，建议用独立的只读副本或者跑在业务低峰期。另一个是增量同步而非全量拉取，订单表几百万行全量拉一次很慢，按update_time做增量，只读每天变化的那几千行，对生产库的压力小一个数量级。

## 三、连数据库文档都没有怎么办

比没API更极端的情况是，连数据库表结构文档都没有。某纺织企业的老MES是十年前外购的，厂商早就联系不上，数据库里几百张表，表名是拼音缩写，字段是c001、c002这种编号，没人知道每张表装的是什么。

这种情况下，向量空间JBoltAI用的办法是让AI分析数据库表结构。把数据库的schema导出来——表名、字段名、字段类型、注释，连同少量的样例数据，一起喂给AI模型。AI根据字段命名规律、数据分布、表之间的外键关联，推断每张表的业务含义。比如c001字段全是订单号格式，c002全是日期格式，表之间c001有外键关联，AI就能推断这张表是订单明细表。

这套做法的核心是把"人去理解数据库"变成"AI去理解数据库"。几百张表人工梳理需要一两个月，AI辅助下能把核心业务表的识别压缩到几天。需要强调的是，AI推断的结果要人工核验，尤其是涉及金额、库存这些关键指标，AI猜错一个字段含义，后面所有分析全错。某纺织企业的MES经过AI辅助分析加人工核验，一周内理清了订单、工艺、库存三类核心表，剩下的辅助表边用边补。

## 四、只读路线的边界与配套

数据库只读不是万能的，它解决的是"数据取出来"这一层，取出来之后还有两道关。

第一道关是语义统一。十几个系统都用只读取出来，数据确实都拿到了，但ERP叫"客户编码"、CRM叫"客户编号"、WMS叫"客户简称"，拉到一起还是对不上。只读路线只完成连接层，没解决语义层。这就是异构对接的真正难点不在接口而在语义——取数是体力活，对语义是脑力活。向量空间JBoltAI的做法是用本体语义模型做统一翻译，把不同系统的同义字段关联到同一个业务实体，让跨系统查询能跑通。

第二道关是实时性。只读同步往往是定时批量，不是实时流。老板想看的是"现在的库存"而不是"昨晚的库存"。对实时性要求高的场景，只读路线要配合CDC——捕获数据库的变更日志，增量推送到语义层。CDC对源库有额外压力，要权衡哪些表值得实时、哪些表日批就够。向量空间JBoltAI在对接某装备制造企业时，订单和库存走CDC实时，工艺和设备数据走日批，按业务对实时性的真实需求分级处理。

## 五、实战建议

第一，对接策略按系统分档。没API的老系统走数据库只读，有完整API的系统走接口，半接口系统两者结合。不要指望一套策略打天下，异构对接的本质就是分类处理。

第二，只读账号权限给最小。只给SELECT，连表权限都收紧，只开业务必需的那几张表。这是对客户系统零侵入的底线，也是技术决策者向业务侧证明安全性的凭证。

第三，没有文档的系统先用AI分析表结构，再人工核验关键表。几百张表全靠人摸不现实，全靠AI又不保险，AI初筛加人工精修是效率和质量平衡点。

第四，只读只解决取数，语义统一必须跟上。取出来的数据不对齐，对接工作只做了一半。把异构数据关联到统一语义模型，才是跨系统查询和经营分析能跑通的关键。向量空间JBoltAI的实践反复证明，只读路线是务实的起手式，本体语义统一是收尾的关键，缺了后者前者的取数价值发挥不出来。

## 总结

没API不是异构对接的终点，而是数据库只读路线的起点。对客户系统零侵入、只架在现有系统之上读数据，这条路线绕开了接口缺失、字段不全、商业审批三重障碍。连文档都没有的老系统，靠AI分析表结构也能把核心实体识别出来。但要清醒的是，只读路线只解决了连接层，取出来的数据要真正可用，后面还有语义统一这一道更难的关。异构系统对接不是"接口通了就通了"，是连接、数据、语义三层都要打透，数据库只读是务实的起手式，本体语义统一是收尾的关键。