Radim Marek：对PostgreSQL视图的深刻见解
💡
原文英文，约4500词，阅读约需17分钟。
📝
内容提要
视图在数据库中是重要的抽象层，能够解耦逻辑意图与物理存储。然而，视图的使用可能带来复杂性和性能问题。创建视图时，列的引用基于属性编号而非名称，可能导致依赖问题。尽管视图提高了安全性和重用性，但其灵活性和可维护性常常受到限制。因此，使用视图时需谨慎，明确列出所有列，并考虑潜在的依赖关系。
🎯
关键要点
- 视图在数据库中是重要的抽象层，能够解耦逻辑意图与物理存储。
- 创建视图时，列的引用基于属性编号而非名称，可能导致依赖问题。
- 视图提高了安全性和重用性，但其灵活性和可维护性常常受到限制。
- 使用视图时需谨慎，明确列出所有列，并考虑潜在的依赖关系。
- 视图的定义在创建时被冻结，后续对基础表的更改可能导致视图失效。
- 在进行表结构更改时，必须手动处理视图的依赖关系，避免使用CASCADE。
- 视图的SELECT *语法会在创建时扩展为具体列，后续添加列不会自动更新视图。
- PostgreSQL的DDL是事务性的，可以在一个事务中安全地进行视图的删除和重建。
- 在使用视图时，建议使用显式列列表，以便更好地管理依赖关系和避免潜在问题。
❓
延伸问答
视图在数据库中的作用是什么？
视图是数据库中的重要抽象层，能够解耦逻辑意图与物理存储。
创建视图时需要注意哪些潜在问题？
创建视图时，列的引用基于属性编号而非名称，可能导致依赖问题。
使用视图有哪些优缺点？
视图提高了安全性和重用性，但其灵活性和可维护性常常受到限制。
如何处理视图的依赖关系？
在进行表结构更改时，必须手动处理视图的依赖关系，避免使用CASCADE。
为什么SELECT *在视图中可能导致问题？
SELECT *在创建时扩展为具体列，后续添加列不会自动更新视图，可能导致缺失列。
PostgreSQL如何处理视图的DDL操作？
PostgreSQL的DDL是事务性的，可以在一个事务中安全地进行视图的删除和重建。
➡️
