数据库中视图能否作为其他视图的数据源？基于视图建视图是否为不良实践？

1. 数据库中能否将视图用作创建其他视图的数据源？ #

当然可以。几乎所有主流关系型数据库（如MySQL、PostgreSQL、SQL Server）都支持以现有视图作为数据源创建新视图。视图本质是存储的查询语句，创建嵌套视图时，数据库会将底层视图的查询逻辑整合进新视图的执行计划中。

2. 基于视图创建视图是否属于不良实践？原因是什么？ #

不能一概而论，需结合场景判断：

• 合理场景：如果是为了复用复杂查询逻辑、分层抽象数据（比如先做数据清洗视图，再基于它构建统计分析视图），这种嵌套能提升代码可维护性，完全没问题。
• 需警惕的不良场景：
  • 过度嵌套：比如嵌套3层以上，会让执行计划优化难度陡增，排查性能问题时很难追踪到底层数据来源。
  • 依赖不稳定视图：若底层视图的结构或逻辑频繁变更，所有依赖它的上层视图都会受影响，大幅提升维护成本。
  • 隐藏性能瓶颈：如果底层视图本身存在低效查询（如无索引的大表全扫），嵌套后会放大性能问题，且难以快速定位根源。

3. 拟创建视图V1作为表T1的子集，通过限定T1某列值为现有视图V2的唯一值，此做法是否合规，还是应使用V2的基表来实现？ #

两种做法都合规，选择哪一种取决于实际需求：

• 优先用V2的情况：如果V2本身就是用来封装“获取该唯一值”的逻辑（比如这个值是经过复杂过滤、计算得到的，且后续可能需要调整逻辑），直接复用V2能保持代码一致性，避免重复编写过滤条件，降低维护成本。
• 优先用V2基表的情况：如果V2的逻辑非常简单，或者你需要避免V2中多余的关联、过滤逻辑影响V1的性能，直接关联基表会更高效，逻辑也更直观。
  另外要注意：如果V2的唯一值是动态变化的，使用V2的话V1会自动继承这个变化；若用基表，则需要手动同步过滤逻辑，否则V1的结果会滞后。

内容的提问来源于stack exchange，提问作者learner