标签：视图 查询 业务员 MySQL 增删 View 数据 VIEW
更新记录
转载请注明出处。
2022年9月3日 发布。
2022年9月3日 从笔记迁移到博客。
说明
视图是虚拟的表，是一种存储结构
可以对视图进行和表一样的操作，但一般用于查询数据
实际的数据仍存储在表中
注意：
视图不是真实的表，但其外在看起来像表
视图不保存实际数据
视图的作用
- 简化数据的操作
从多个数据表，方便提取需要的数据 - 对外提供一个统一的接口
计算列的需要，数据库设计范式要求我们减少冗余字段，因此现在很多数据表都没有计算列字段，如采购单：有价格、数量、税率、含税金额，多半没有不含税金额、税额，而这些字段在很多报表中有都会用到，所以我们可以创建一个含有计算列字段的视图来解决这个问题
不同表字段聚合，信息重组，如：经销商通常有业务员，业务员通常有上下级关系（客户经理、区域经理、大区经理等），因此查看经销商业务员时我们需要看到直管业务员是谁？该业务员对应的区域经理、大区经理是谁（可能NULL）？因此我们可以联合经销商表、业务员信息表、业务员上下级关系表定义一个经销商视图 - 增加数据库安全性
安全性需要，主要是早期遗留系统集成需要，如：需要xx系统数据，又没接口，怎么办？直接操作数据库，这时就涉及数据安全性，合理利用视图则可以减少很多授权工作和保证数据安全性。当下新构建的系统几乎都是暴露api接口，因此数据安全性更多关注在接口的身份认证和数据粒度方面 - 兼容老的数据表
曾经碰到过这么个问题。公司自主研发的进销存管理系统，一开始自用的，后来合作伙伴企业也要用，所以打算Saas化，当初做了一个最大的变动就是几乎所有表增加了一个使用单位(co_id)字段。悲催的是另外一个外购系统用到了采购单表，该系统已经停止维护、又继续在用。于是就创建了一个co_id=自有公司的视图，命名为原采购单表，而原采购单表改成新表名。这样一来外购系统可以继续使用，而且数据也没问题
视图的缺点
首先视图是一个虚表，很多在表上性能优化的手法可能就没有，而且数据库引擎要构建视图有一个过程，类似一个查询，视图的性能以及优化你就不要又太高的要求。你可以把他看作一个查询，而不是一个表真的优化也最好基于查询的优化来优化可能好一些
视图限制
一般情况下，视图只用于查询使用，而不是用于数据的增删改
视图的增删改语法上和表的增删改相同
注意以下情况视图无法增删改数据：
包含聚合函数SUM()/AVG()/COUNT()/MAX()/MIN()等
视图中包含UNION/UNION ALL/DISTINCT/GROUP BY/HAVING等
包含常量或字符串
SQL语句中包含子查询
由视图导出的视图
ALGORITHM为TEMPTABLE类型
所以视图最好是用于查询，而不是增删改
定义视图/创建视图
CREATE [ALGORITHM={UNDEFINED | MERGE | TEMPTABLE}]
VIEW [(自定义属性名....)]
AS SQL语句
[WITH [CASACED|LOCAL] CHECK OPTION];
查看视图
DESC 视图名;
SHOW CREATE VIEW 视图名;
修改视图
CREATE OR REPLACE [ALGORITHM = UNDEFINED|MERGE|TEMPTABLE]
VIEW 视图名 [(属性)]
AS SQL语句
[WITH [CASCADED|LOCAL] CHECK OPTION];
或者
ALTER [ALGORITHM = UNDEFINED|MERGE|TEMPTABLE]
VIEW 视图名 [(属性)]
AS SQL语句
[WITH CASCADED|LOCAL CHECK OPTION];
删除视图
DROP VIEW [IF EXISTS] 视图名;
注意：删除视图之前记得检查是否有其他视图依赖该视图。
标签：视图,查询,业务员,MySQL,增删,View,数据,VIEW 来源： https://www.cnblogs.com/cqpanda/p/16652019.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。