在 SAP HANA 的远程数据访问体系里，真正让远端数据库里的表进入本地 SQL 世界的那个关键动作，并不是复制数据，而是创建 Virtual Table。前面完成 Remote Source 配置以后，SAP HANA 已经知道远端系统在哪里、应该使用哪一种 Adapter、如何建立连接，也知道访问远端系统时采用什么身份。但是站在数据库开发人员的角度，这时还不能像查询普通 HANA 表那样直接操作某个远程业务表。两者之间还缺了一层映射。这一层，就是 Virtual Table。围绕 Remote Source 的完整链路来看，逻辑关系其实非常清晰。Remote Source 负责描述远端系统以及连接能力，Remote Object 是远端系统真实存在的数据库对象，Virtual Table 则是在本地 SAP HANA Catalog 中建立的一个虚拟数据库对象。应用程序最终面对的是 Virtual Table，而真正的数据仍然可以留在远端。SAP 官方对 Virtual Table 的定义也非常明确。Virtual Table 可以指向 Remote Source 中的远程表或者远程视图。当 SQL 查询访问 Virtual Table 时，SAP HANA 可以像处理本地表一样把它放入查询计划，同时通过 Smart Data Access 等机制访问远程数据，而不必预先把整张远端表复制进入本地 SAP HANA。这一点恰恰是理解 Create Virtual Tables 最重要的起点。假设企业里已经存在一套 SAP S/4HANA 业务系统，销售订单、物料、客户等核心数据都保存在业务数据库中。另一边还有一套 SAP HANA Clou
在 SAP HANA 的远程数据访问体系里，真正让远端数据库里的表进入本地 SQL 世界的那个关键动作，并不是复制数据，而是创建 Virtual Table。前面完成 Remote Source 配置以后，SAP HANA 已经知道远端系统在哪里、应该使用哪一种 Adapter、如何建立连接，也知道访问远端系统时采用什么身份。但是站在数据库开发人员的角度，这时还不能像查询普通 HANA 表那样直接操作某个远程业务表。两者之间还缺了一层映射。这一层，就是 Virtual Table。围绕 Remote Source 的完整链路来看，逻辑关系其实非常清晰。Remote Source 负责描述远端系统以及连接能力，Remote Object 是远端系统真实存在的数据库对象，Virtual Table 则是在本地 SAP HANA Catalog 中建立的一个虚拟数据库对象。应用程序最终面对的是 Virtual Table，而真正的数据仍然可以留在远端。SAP 官方对 Virtual Table 的定义也非常明确。Virtual Table 可以指向 Remote Source 中的远程表或者远程视图。当 SQL 查询访问 Virtual Table 时，SAP HANA 可以像处理本地表一样把它放入查询计划，同时通过 Smart Data Access 等机制访问远程数据，而不必预先把整张远端表复制进入本地 SAP HANA。这一点恰恰是理解 Create Virtual Tables 最重要的起点。假设企业里已经存在一套 SAP S/4HANA 业务系统，销售订单、物料、客户等核心数据都保存在业务数据库中。另一边还有一套 SAP HANA Clou
