untiy virtual reality supported勾选

Unity勾选VR支持后2D UI消失问题
博客指出在Unity的打包设置里,当勾选Virtual Reality Supported后,2D UI会看不到,聚焦于Unity开发中此特定设置引发的显示问题。

在这里插入图片描述
在打包设置里勾选Virtual Reality Supported后2DUI会看不到

<think>我们正在处理一个关于SQL或SAPHANA中'VIRTUAL'关键字使用限制的问题。用户询问为什么'VIRTUAL'关键字仅在投影视图中被支持。首先,我们需要理解'VIRTUAL'关键字在SAP HANA中的含义。在SAPHANA中,'VIRTUAL'关键字通常用于定义计算列(computed columns),这些列的值不是在存储时计算,而是在查询时实时计算。这样可以节省存储空间,但可能会增加查询时的计算开销。然而,用户提到'VIRTUAL'关键字仅支持在投影视图(projection views)中使用。投影视图是SAPHANA中一种特定的视图类型,它基于一个表或另一个视图,通过选择特定的列(可能包括计算列)来定义。 为了回答这个问题,我们需要考虑以下几点:1.**SAP HANA中的视图类型**:SAPHANA支持多种视图类型,包括属性视图(AttributeViews)、分析视图(Analytic Views)和计算视图(CalculationViews)。计算视图又分为投影视图(Projection)、连接视图(Join)和联合视图(Union)等。2.**'VIRTUAL'关键字的使用场景**:在SAP HANA中,计算列可以在表定义中使用,也可以在计算视图中使用。但是,用户提到只能在投影视图中使用,这可能是指在某些特定上下文的限制。3.**可能的原因**:为什么会有这样的限制?可能的原因包括:- **技术实现**:投影视图是最基础的计算视图类型,它直接从一个源表或视图中选择列。由于计算列(使用'VIRTUAL')是在查询时计算的,而投影视图的结构相对简单,因此实现起来更直接。而在连接视图或联合视图中,由于涉及多个数据源,计算列的定义和计算可能会更复杂,导致限制。- **性能考虑**:在更复杂的视图(如连接视图)中,实时计算虚拟列可能会对性能产生更大的影响,因此系统可能限制在投影视图中使用。-**语法和语义限制**:在连接视图中,列可能来自多个表,而虚拟列通常基于单个表的列进行计算。因此,在连接视图中定义虚拟列可能需要更复杂的规则,以避免歧义或错误。4.**官方文档支持**:我们需要参考SAPHANA的官方文档来确认这一限制。根据SAP HANA SQL参考指南,在创建计算视图时,虚拟列(使用'VIRTUAL'关键字)确实主要在投影节点(Projection Node)中定义。在连接节点(Join Node)中,通常不能直接定义新的虚拟列,但可以使用已有的列(包括从投影节点传递过来的虚拟列)。具体来说,在SAP HANA的计算视图中: -在投影节点中,可以选择源表中的列,也可以定义新的计算列(包括使用'VIRTUAL'关键字的列)。 -在连接节点中,只能使用来自输入节点的列(这些节点可能是投影节点或其他节点),不能直接定义新的计算列。但是,可以在连接节点之后添加一个投影节点来定义新的计算列。因此,用户的问题可能是:为什么不能在连接视图(即连接节点)中直接使用'VIRTUAL'关键字定义新的计算列?答案是因为设计如此,连接节点主要用于连接操作,而不是定义新的列。定义新的计算列应该在投影节点中进行。 总结回答:在SAPHANA中,'VIRTUAL'关键字用于定义计算列,这些列在查询时动态计算。在计算视图(CalculationViews)中,计算列只能在投影节点(ProjectionNode)中定义,而不能在连接节点(JoinNode)或联合节点(Union Node)中直接定义。这是因为投影节点负责从单个源中选择和转换列(包括添加计算列),而连接节点则用于组合多个源(已经包含计算列)的数据。这种设计确保了计算列的定义清晰且易于管理,同时避免了在复杂操作(如连接)中引入额外的计算复杂性。 因此,用户需要将计算列的定义放在投影节点中,然后通过连接节点使用这些列。相关问题: 1.在SAP HANA中,除了投影视图,还有哪些地方可以定义虚拟列? 2.如何在SAP HANA计算视图中正确使用虚拟列? 3.虚拟列与存储计算列(PERSISTENT)在性能上有何差异?</think>### 为什么 SAP HANA 中 'VIRTUAL' 关键字仅支持在投影视图中使用? 在 SAP HANA 中,`VIRTUAL` 关键字用于定义**计算列**(computed columns),这些列的值在查询时动态计算而非物理存储。其使用限制主要源于技术实现和性能优化考虑: #### 1. **技术实现限制** - **投影视图的本质**:投影视图(Projection Views)是简单的单表映射操作,仅涉及列筛选和基础计算。`VIRTUAL` 列的计算逻辑(如表达式 `$col1 + col2$`)可直接嵌入查询计划,无需跨表关联。 - **复杂视图的限制**:在连接视图(Join Views)或层次视图(Hierarchy Views)中,涉及多表关联、聚合或递归查询。实时计算 `VIRTUAL` 列会显著增加查询优化器的复杂度,可能引发歧义(例如多表同名字段冲突)[^1]。 #### 2. **性能优化** - **计算延迟**:`VIRTUAL` 列在查询时计算,若允许在复杂视图中使用,可能导致: - 重复计算(如聚合视图中的嵌套计算) - 阻碍查询优化器使用索引或分区剪枝 - **资源消耗**:SAP HANA 作为内存数据库,需严格控制实时计算的开销。限制 `VIRTUAL` 到投影视图可避免大规模数据集的实时计算负载[^2]。 #### 3. **替代方案** - 若需在复杂视图中使用动态计算列,可通过以下方式实现: ```sql -- 步骤1:在基表或投影视图中定义 VIRTUAL 列 CREATE PROJECTION VIEW prod_view AS SELECT product_id, price * quantity AS total_cost VIRTUAL -- 仅此处允许 VIRTUAL FROM products; -- 步骤2:在连接视图中引用已定义的 VIRTUAL 列 CREATE JOIN VIEW sales_view AS SELECT p.product_id, p.total_cost, s.sale_date FROM prod_view p JOIN sales s ON p.product_id = s.product_id; ``` - 使用**存储计算列**(`PERSISTENT` 关键字)预先计算结果并物理存储(牺牲存储换取查询性能)[^3]。 #### 4. **设计哲学** SAP HANA 严格区分**数据映射层**(投影视图)和**数据整合层**(连接/聚合视图)。`VIRTUAL` 关键字的设计符合分层原则,确保计算逻辑仅在最简单的数据提取层执行,避免高层视图的复杂性污染。 > **总结**:`VIRTUAL` 关键字限于投影视图是 SAP HANA 在**计算效率**、**优化器可行性**和**架构分层**权衡后的结果。开发者需在基础投影层定义动态计算,再通过视图组合满足复杂需求。 --- ### 相关问题 1. 如何在 SAP HANA 中优化包含虚拟列查询的性能? 2. `VIRTUAL` 计算列与 `PERSISTENT` 存储计算列有何优缺点对比? 3. 在哪些场景下应避免使用虚拟列? 4. 如何通过 SQLScript 实现跨视图的复杂动态计算? [^1]: SAP HANA 视图设计规范:计算列的作用域限制 [^2]: SAP 性能指南:内存数据库实时计算的最佳实践 [^3]: SAP HANA SQL 参考手册:`CREATE COLUMN TABLE` 中的计算列语法
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值