为代码减负之<三>视图(SQL)

在设计数据库时为了降低数据冗余。一般都会依照三范式去设计,但有时我们在查询时须要通过一字段获取跟这

个字段相关联的好几个字段。可是他们又分布在不同的表中,这时候假设依照正常途径走的话须要同一时候查询好几张

表,不仅操作麻烦还easy出错。当然我们有捷径。把想要查询的字段都整合到一张虚拟表中,这就是视图的应用。

简介

    概念:视图是从若干基本表或其它视图构造出来的表,是一张虚拟的表。其内容由查询定义。

同真实的表一样。

视图包括一系列带有名称的列和行数据。

可是视图并不在数据库中以存储的数据值集形式存在。

行和列数据来自由定

义视图的查询所引用的表,而且在引用视图时动态生成。

视图的长处:

一,视图着重于特定数据。

视图能够让用户或者程序开发者仅仅看到他们所须要的数据,而不须要把表中的全部信息与字段暴露出来,这样增强了数据的安全性。

二。简化数据的操作,易维护。

我们能够将经经常使用到的多表联合查询出来的数据,或特定的结果集定义为视图,这样就起到了模块化数据的作用。

我们在使用这些数据时直接查询该视图就能够。而不用到处写长长的SQL语句,这样也起到易维护的作用。

三,视图能够限定查询数据。

比方:对于不同的用户,我们仅仅提供部分数据给他。这样,我们就能够在视图中限定结果集。然后返回该视图给他。这样。不管用户怎么对视图定义查询条件。他也不能查询出我们不想提供给他的数据。

小小试炼

在设计机房收费系统的数据库时为了降低数据冗余。把原先的学生表,分成了两个表即卡表和学生表。卡表仅仅存

放卡的信息,学生表仅仅存放学生的信息。这样是遵从了三范式的要求。可是在查询信息的时候却不能像原来那样

方便,须要同一时候查询这两个表。所以在此尝试了视图。

1. 新建视图

2. 选择涉及到的表或视图

3. 选择各个表中须要查询的字段

4. 命名保存

5. 实际应用

和普通表一样进行查询就可以。"select * from StuCardView_info where
[email protected]"

尽管视图能够给我们带来种种便利。但不意味着我们就能够滥用它。

由于视图事实上就是一段SQL语句。所以它的结果都是每次调用时动态生成的。假设不合理的定义视图,必定带来性能上的损耗。

以下是我们在创建视图应该要注意的几点:

1. 操作视图会比直接操作基础表要慢。所以我们尽量避免在大型表上创建视图。

2. 尽量不要创建嵌套视图,就是在视图中使用视图。这样在查询时。会多次反复訪问基础表,带来性能损耗。

3. 尽量在视图仅仅返回所需的信息,尽量不要在视图使用不须要訪问的表。

4. 在大型表或者复杂定义的视图,能够使用存储过程取代。

5. 频繁使用的视图,能够使用索引视图来取代。

对视图的理解还非常浅显。以上的实例也仅仅是视图的最基本应用。其他诸如索引视图、切割视图、汇总视图等还没

详细应用过。

对视图的更新操作也没尝试,须要做的还有非常多。

时间: 2024-08-25 20:11:23

为代码减负之<三>视图(SQL)的相关文章

为代码减负之<三>视图(SQL)

在设计数据库时为了减少数据冗余,一般都会按照三范式去设计,但有时我们在查询时需要通过一字段获取跟这 个字段相关联的好几个字段,但是他们又分布在不同的表中,这时候如果按照正常途径走的话需要同时查询好几张 表,不仅操作麻烦还容易出错.当然我们有捷径,把想要查询的字段都整合到一张虚拟表中,这就是视图的应用. 简单介绍     概念:视图是从若干基本表或其他视图构造出来的表,是一张虚拟的表,其内容由查询定义.同真实的表一样, 视图包含一系列带有名称的列和行数据.但是视图并不在数据库中以存储的数据值集形式

Django基础三之视图函数

Django基础三之视图函数 本节目录 一 Django的视图函数view 二 CBV和FBV 三 使用Mixin 四 给视图加装饰器 五 Request对象 六 Response对象 一 Django的视图函数view 一个视图函数(类),简称视图,是一个简单的Python 函数(类),它接受Web请求并且返回Web响应. 响应可以是一张网页的HTML内容,一个重定向,一个404错误,一个XML文档,或者一张图片. 无论视图本身包含什么逻辑,都要返回响应.代码写在哪里也无所谓,只要它在你当前项

序列化组件三,视图函数家族

一.多表查询序列化类外键字段的覆盖 """ 1)在序列化类中自定义字段,名字与model类中属性名一致,就称之为覆盖操作 (覆盖的是属性的所有规则:extra_kwargs中指定的简易规则.model字段提供的默认规则.数据库唯一约束等哪些规则) 2)外键覆盖字段用PrimaryKeyRelatedField来实现,可以做到只读.只写.可读可写三种形式 只读:read_only=True 只写:queryset=关联表的queryset, write_only=True 可读

SQL Server -为代码减负之触发器

触发器是一张表的增删改操作,引起或触发对另一张表的增删改操作,所以触发器便有3种类型,分别是deleted触发器,Update触发器,insert触发器 触发器又根据替换原来的增删改操作,还是在原来的增删改完成之后进行增删改操作,分为Instead of触发器和For或者After触发器(for和after属于一种触发器) 触发器的使用涉及到两张非常重要的表用来保存已经改变或者已经在第一章被操作的表上不存在的记录,分别是虚拟表Inserted和虚拟表Deleted 虚拟表Inserted 虚拟表

为代码减负之<二>存储过程(SQL)

在上篇博客中介绍到了触发器的使用,并且其中也提到了触发器是个特殊的存储过程,那么什么是存储过程呢?他们 两个又到底有什么区别呢? 其实最主要的区别就是,触发器是当满足条件时系统自动执行的,而存储过程是手动调用的. 简单介绍 什么是存储过程? 定义:将常用的或很复杂的工作,预先用SQL语句写好并用一个指定的名称存储起来,用户通过指定存储过程的名字 并给出参数(如果该存储过程带有参数)来调用它. 讲到这里,可能有人要问:这么说存储过程不就是一堆SQL语句而已吗?那么存储过程与一般的SQL语句有什么区

BPMN规范中的三种视图

诚如UML建模所带来的好处一样,对流程建模规范BPMN也同样带来了类似好处,此外BPMN还通过一套统一的建模.执行模型缩小了业务人员和开发人员之间的一道鸿沟,而其终极目标也包含消除这道鸿沟.亦如UML用十四种图来描述一个系统的不同方面,对于BPM而言,BPMN提供了三种基本类型的流程视图,而这也成为不同角色之间交流业务流程.创建端到端的业务流程的基础.本文将简单描述这几种流程视图_--协作视图(Collaboration).流程视图(process).编排视图(choreography). 协作

Laravel教程 三:视图变量传递和Blade

Laravel教程 三:视图变量传递和Blade 此文章为原创文章,未经同意,禁止转载. Blade 上一篇我们简单地说了Router,Views和Controllers的工作流程,这一次我就按照上一篇的计划,来说说下面几个内容: 向视图中传递变量 Blade模板的用法 向视图中传递变量 我们在开发web应用当中,通常都不是为了写静态页面而生的,我们需要跟数据打交道,那么这个时候,问题就来了,在一个MVC的框架中,怎么将数据传给视图呢?比如我们要在 ArticleController 的 ind

为代码减负之<一>触发器(SQL)

对触发器一词早有耳闻(最早是在耿大妈的数据库视频中),当初看完视频后,对理解不深刻的东西如:触发器,存储过程,事务,日志等等没有详细的去查阅,也没有具体的去尝试,应用.所以才导致了今天的博客(把以前丢下的补上).提到触发器一词,首先想到的是"触发器不能乱用","慎用触发器",不过我们可不能把这些提醒的话,当成了自己不去尝试的借口.学习要有无知者无畏的精神,管他呢,先试了再说. 简单介绍 概念:触发器是个特殊的存储过程(存储过程下篇博客中会讲到),它的执行不是由程序调

第三曲-视图与控制器的完美交融

我们使用图纸来简单地描绘一下MVC模式: 到了后面你就会发现,这种方式十分优雅,简洁.符合KISS原则.顺便一提,控制器和视图都不处理逻辑的,逻辑处理全交给了模型,这可能和你以前接触到的有些许不同.不过我们马上就会看到MVC是如何优雅地处理模型. 接下来我们再看到视图,并把目光聚焦于布局视图.我们可以轻松地在Views/Shared下找到布局视图,MVC采用命名优先的方式来构建程序,也就是说只要你的名字符合某种规范,就不需要到处初始化,注册什么的了. 由于代码过多,我就不贴出来了,不出意外的话我