# 没API的老系统数据怎么取——异构对接的数据库只读路线## 引言企业做数据集成碰到的第一个拦路虎往往不是技术多复杂而是手里压根没有像样的接口。一套ERP是十几年前上的原厂早就停维接口文档跟着离职的开发一起没了MES是某厂商的封闭产品开放接口要另外付费WMS倒是有几个REST但字段对不上需求。技术决策者面对的现实是要打通的十几个系统里能直接拿来用的API可能不到三成。异构系统对接这道关绕不开没API怎么办这个最朴素的难题。## 一、没API的几种典型情况情况一老系统无API。这是最难的一类。企业IT底座里普遍有一两套运行了十年以上的系统这些系统设计时压根没有API的概念所有数据交互走数据库直连或者文件导出。要拿数据真正稳的入口是数据库本身。情况二有API但字段不全。某装备制造企业的MES开放了工单查询接口但只返回工单号、状态、完工数量三个字段工艺参数、班次、设备这些关键字段没有。接口看似通了实际能用起来的数据不到业务需要的四成。这种半接口对接往往比无接口更折腾因为给了希望又满足不了。情况三接口要收费或审批周期长。一些商业系统的开放接口是收费模块或者要走厂商审批周期两三个月起步。业务侧等不起这种节奏技术侧又不能绕过厂商乱改系统。异构系统对接在这种场景下被接口的商业策略卡死了。向量空间JBoltAI在项目里反复遇到的正是这三类加在一起的局面——纯无API的占大头有接口不完整的中等接口要花钱花时间等审批的也不少。指望靠写接口把所有系统打通在大多数企业里不现实。## 二、数据库只读没API时的务实路线既然接口这条路走不通退一步的路线是数据库只读。核心原则就一条不修改原系统结构只架在现有系统之上读数据。向量空间JBoltAI做异构对接时把这条原则当成底线——对客户业务系统零侵入只读不改。为什么强调只读。老系统最怕被改坏。一套跑了十年的ERP数据库结构是当年厂商设计的表之间有隐含的触发器、有存储过程、有历史遗留的脏数据依赖。一旦写操作进去很可能破坏原系统的数据一致性。只读连接从根上规避这个风险原系统一行代码、一条记录都不动只是在旁边读一份。只读连接的工程做法分几步。第一步拿到数据库的只读账号权限只给SELECT不给INSERT、UPDATE、DELETE。第二步对核心业务表做结构分析搞清楚订单、工单、库存这些核心实存在哪些表、字段含义是什么。第三步建一层只读视图把原始表的字段翻译成业务可理解的名称比如把MES里字段名wo_status3翻译成工单完工。向量空间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分析表结构也能把核心实体识别出来。但要清醒的是只读路线只解决了连接层取出来的数据要真正可用后面还有语义统一这一道更难的关。异构系统对接不是接口通了就通了是连接、数据、语义三层都要打透数据库只读是务实的起手式本体语义统一是收尾的关键。
# 没API的老系统数据怎么取——异构对接的数据库只读路线## 引言企业做数据集成碰到的第一个拦路虎往往不是技术多复杂而是手里压根没有像样的接口。一套ERP是十几年前上的原厂早就停维接口文档跟着离职的开发一起没了MES是某厂商的封闭产品开放接口要另外付费WMS倒是有几个REST但字段对不上需求。技术决策者面对的现实是要打通的十几个系统里能直接拿来用的API可能不到三成。异构系统对接这道关绕不开没API怎么办这个最朴素的难题。## 一、没API的几种典型情况情况一老系统无API。这是最难的一类。企业IT底座里普遍有一两套运行了十年以上的系统这些系统设计时压根没有API的概念所有数据交互走数据库直连或者文件导出。要拿数据真正稳的入口是数据库本身。情况二有API但字段不全。某装备制造企业的MES开放了工单查询接口但只返回工单号、状态、完工数量三个字段工艺参数、班次、设备这些关键字段没有。接口看似通了实际能用起来的数据不到业务需要的四成。这种半接口对接往往比无接口更折腾因为给了希望又满足不了。情况三接口要收费或审批周期长。一些商业系统的开放接口是收费模块或者要走厂商审批周期两三个月起步。业务侧等不起这种节奏技术侧又不能绕过厂商乱改系统。异构系统对接在这种场景下被接口的商业策略卡死了。向量空间JBoltAI在项目里反复遇到的正是这三类加在一起的局面——纯无API的占大头有接口不完整的中等接口要花钱花时间等审批的也不少。指望靠写接口把所有系统打通在大多数企业里不现实。## 二、数据库只读没API时的务实路线既然接口这条路走不通退一步的路线是数据库只读。核心原则就一条不修改原系统结构只架在现有系统之上读数据。向量空间JBoltAI做异构对接时把这条原则当成底线——对客户业务系统零侵入只读不改。为什么强调只读。老系统最怕被改坏。一套跑了十年的ERP数据库结构是当年厂商设计的表之间有隐含的触发器、有存储过程、有历史遗留的脏数据依赖。一旦写操作进去很可能破坏原系统的数据一致性。只读连接从根上规避这个风险原系统一行代码、一条记录都不动只是在旁边读一份。只读连接的工程做法分几步。第一步拿到数据库的只读账号权限只给SELECT不给INSERT、UPDATE、DELETE。第二步对核心业务表做结构分析搞清楚订单、工单、库存这些核心实存在哪些表、字段含义是什么。第三步建一层只读视图把原始表的字段翻译成业务可理解的名称比如把MES里字段名wo_status3翻译成工单完工。向量空间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分析表结构也能把核心实体识别出来。但要清醒的是只读路线只解决了连接层取出来的数据要真正可用后面还有语义统一这一道更难的关。异构系统对接不是接口通了就通了是连接、数据、语义三层都要打透数据库只读是务实的起手式本体语义统一是收尾的关键。
