虚拟表使Dataverse得以呈现存于他处之数据——SQL Server、Cosmos DB、REST API——而无需将其复制入Dataverse。用户所见之体验，与寻常表格无异：视图、表单、查询、关联。其根本检索，每读必越网线，至外部之源。
纸面观之，其引人之趣昭然：无同步之弊，无重复之扰，恒保其新。然实践之中，迟滞之性乃决其是否合乎用。今列三式，凡议虚拟之表者，必以之较之，并陈其规。
虚拟之表者何（虚拟之表者非何）
虚拟之表于Dataverse中，其定义在：
- 一虚拟之实体（表之式）
- 虚拟实体提供者（为Dataverse与外部数据源之桥梁）
- 元数据映射（外部数据源之列名与类型至Dataverse视图）
当用户开启虚拟表之视图时，Dataverse即唤此提供者。提供者询外部数据源。结果回传，乃呈现之。
至要者：
- 无数据存于Dataverse。虛表不存一行。
- 与原表之關係有制。可自原表查虛表；不可有匯總，亦不可有涉虛表之複雜跨表查詢。
- 無審計，無欄級安全，無重複檢測。依賴存於Dataverse之功能皆不適用。
吾所行之标尺
未尝定于虚案，先设三境以测之。
- 单行检索：依主键取一行。"启详单。"
- 列表视：以滤器取50行。"载活跃订单之默认视。"
- 集成写入及回读：原表行即得创建，与虚表相系；表单立时显合数据。
量端至端迟滞，自Power平台主调至应答可呈。目：
- 单行索：五百毫秒以下
- 列视：一千二百毫秒以下
- 写入及回读：二秒以下
虚拟表之后有 SQL Server，属地区域
此为 Azure 区域内 Dataverse 环境同地托管之 SQL Server 数据库之典型基准，常态负载下：
- 单行检索：150-300毫秒（佳）
- 列表视之：400-900毫秒（佳）
- 写入并回读：800-1500毫秒（尚可，可运作）
主导之费，乃网络往返加SQL查询之计划。同址SQL于多数情境中表现尚可。
此法可行之时：索购物史，引据数据，其本源在库；作报类观，数据浩繁，复之非宜。
范式二：虚拟之案后，有 REST API，经由互联网路由之
API寓于客户之基构或第三方之服务，非共址：
- 单行检索：800-1500毫秒（微弱）
- 列视：2000-5000毫秒（劣）
- 写及回读：3000-6000毫秒（失二秒之限）
API之呼增每呼基线迟滞300-800毫秒。列五十行需多后端查询者，积速甚速。
此法不效时：凡用户目之所及，一时显五十行以上者。逐表索骥可行；视窗载入则不然。
此法可行时：低频场景，用户可忍加载之旋，所引数据鲜变，可纵力缓存。
模式三：虚表配供端缓存
巧思之设：于数据宇宙与外源间，置一缓存（Redis，Cosmos DB 配时效，或 SQL Server 充缓存之表）。虚拟实体之供，取自缓存；别一之程，恒使缓存新自真源。
- 单行索检：八十至百五十毫秒（优）
- 列观之览：二百至五百毫秒（优）
- 写而复读：四百至八百毫秒（良）
权衡：缓存引致陈旧。 backing source 中更改之行列，或需秒至分钟，视缓存刷新之策而定，方显于 Dataverse。
此模式得效之时：读量高而写量低，用户可容短暂陈旧。多见于报章引用之数据境。
当此模式繁复时：缓存今为独立系统，以监之、使无效、令其老。增操作之面.
择虚拟表之前，有三问.
- 数据几何？
不满十万行，且增缓：但录之入本Dataverse表，经数据流。得平台全备之能，无性能之患。
逾千萬行，或迅疾增長：虛擬表格漸顯其美。藏十萬行於Dataverse，耗容量費。
其间：审度他二者之问而决之。
- 数据更迭几何？
变故鲜有（参考数据、史册）：土生土长之表，以数据流周期同步，已足矣。虚拟之表，于汝无益。
更迭频仍（如运行时数据、实时交易、物联网遥测）：若源支持，虚拟表或可适宜；否则，需同步加缓存之模式。
- 人何以与之交？
游目观览，深入探赜（列视，详表）：若迟滞可容，依式一或式三，虚拟之表可用。
批量操作（大规模编辑、导入、跨数百万行进行报告查询）：虚拟表非宜。外源将遭重击；数据域将超时。
查找字段目标（原生表引用虚拟表之行）：可行，然任何导航将中断汇总与计算列。
去年吾辈所为之比试
有客欲其SQL Server之十五万行订单史，得见于Dynamics Sales之界面。议其三策：
- 尽录十五万行于Dataverse：耗Dataverse之容量，月更其同步，滞数据至二十四时。
- 设虛表，直通SQL：实时数据，无存储之费，每视之迟滞四百至九百毫秒。
- 虚拟表配以Cosmos DB缓存：近实时数据（缓存TTL三十秒），读取迅捷（150-300毫秒），然增操作之繁复.
吾等于UAT环境克隆中，试三法。一法之费，仅Dataverse存储计年十二千。二法之观，峰时犹滞（SQL争用）。三法则胜于价与效。
唯有一忌：择三则需投运以养缓存。吾辈筑监控之台，复于其上设缓存预热之序。客户内人继之，九载未尝有恙。
吾辈不荐虚席之时
有三境，吾等导客远离虚表：
- 重写之境。虛表供應者必須實現創/改/刪，而排錯供應端交易語義之難，遠甚於排錯尋常之增刪改查。
- 需求特徵，欲求虛擬世界本然之行為。欄級安全、審計、警報、重複檢測、業務流程流轉——此諸者，皆不適於虛表。
- 参考数据量稀少。不满五千行，但可直抄。所省工程之工，值容量之费。
虚拟表乃专应规模与数据新度之器。然于多数"别处已有旧数据"之境，非首择之策。数据宜抄，除非有特异之由。