精华内容
下载资源
问答
  • 利用视图进行多表关联

    千次阅读 2018-07-10 21:46:15
    可是我们就是要在一张关联10,比如一张中的很字段都要关联码表,因为其有对应的翻译字段。那我们改怎么办呢? 只能将他分成俩次进行关联。 难不成我们要重新创建一个中间就是为了关联一下么?...

    疑问

    在Maxcompute中我们关联的码表大于8个,然后数据存储量大于500W,那么在进行sql清洗的时候极有可能会被卡死。可是我们就是要在一张表上关联10多个表,比如一张表中的很多字段都要关联码表,因为其有对应的翻译字段。那我们改怎么办呢?


    • 只能将他分成俩次进行关联。

    • 难不成我们要重新创建一个中间表就是为了关联一下么?卧槽,这也太操蛋了吧。

    答案

    答案流程
    1、面对这样的问题的时候sql中伟大的视图出现了,他就当做个第三方的中间机制。

    2、将第一个表和8个代码表进行关联的表进行虚拟化,在sql的内部形成一个虚拟的整体。除了不存在于数据库中的表面和表结构之外,真实表中所有的属性他都有。可以进行任意的内置函数的操作。

    3、那么在后面我们要关联剩下的要关联的表和这张假皮(视图)进行关联操作了。这样所有需要翻译、关联的代码表就都关联上了。

    4、这样我们可以类推:我们有30个要关联的表怎么办,那么我们是不是就把这三十个字段进行切分,形成3个视图+一个实体表就可以了。

    5、 最后也是一个视图+一个实体表的关联。因为下一个表(无论是视图还是实体表)的数据来源是不是都是来自于上一个表,那么上一个表+新增关联码表=下一个视图或者实体表。只是在最后的实体表我们才能表所有的数据写进去。
    视图也会有分区的概念的。
    这里写图片描述

    下面时我们最爱的DEMO环节(一个视图+一个实体表)

    ---逐层关联---
    DROP VIEW EXISTS  t_znb_xs_df_view_1;               --表名_view_1,便于区分
    CREATE VIEW t_znb_xs_df_view_1  AS
    SELECT  /*+mapjoin (t1、t2、t3、t4、t5、t6、t7、t8)*/
    t.id as id ,        --原表属性    
    t.xb as xb,     --原表属性
    t1.codename as xb_dm,       --关联码表产生的字段
    ......
    FROM (
    SELECT
    string_convert(t0.id) as id,        -- 去除xm字段中的‘/ , ’这样的无聊字符,这一步的清理一般而言就是只需要使用在汇聚层之中就可以了,因为汇聚层中的数据比较杂乱无章,都是各个部门汇聚过来的信息。string_convert()这个函数是我们自己写的。
    string_convert(t0.hqdw) as hqdw,        --去除xm字段中的‘/ , ’这样的无聊字符
    from 汇聚库表名 t0 where pt='${pt-1}' )t
    row_number() over (partition by id order by xm desc) as rn      -- 去重
    left outer join (SELECT codetype,code,codename FROM 代码库.代码表 WHERE codetype='XB') h on t.xb=h.code
    .........
    where a.rn=1;
    
    ----此时视图中的数据已经建立完成----
    ----真假相遇咯,下面我们就来把这个假皮和真皮相关联-----
    
    ----逐层关联----
    
    
    insert overwrite table t_znb_xs_df parttion (pt='${bdp.system.bizdate}')
    select /*+mapjoin (t9、t10、t11、t12、t13、t14、t15、t16)*/
    md5(concat(id)) as JL_ZJ,
    null as JL_XXMJ,
    from t_znb_xs_df_view_1 t 
    left outer join (SELECT codetype,code,codename FROM 代码库.代码表 WHERE codetype='XB') h on t.xb=h.code;

    因为上面已经去过重了,下面就不去重了
    这里写图片描述

    展开全文
  • 干货 | Elasticsearch多表关联设计指南

    万次阅读 多人点赞 2019-03-24 23:45:37
    Elasticsearch多表关联问题是讨论最多的问题之一,如:博客和评论的关系,用户和爱好的关系。 多表关联通常指:1对多,或者多对多。 本文以星球问题会出发点,引申出ES多表关联认知,分析了4种关联关系的适用场景...

    Elasticsearch 最少必要知识实战教程直播回放

    0、题记

    Elasticsearch多表关联问题是讨论最多的问题之一,如:博客和评论的关系,用户和爱好的关系。
    多表关联通常指:1对多,或者多对多。
    本文以星球问题会出发点,引申出ES多表关联认知,分析了4种关联关系的适用场景、优点、缺点,
    希望对你有所启发,为你的多表关联方案选型、实战提供帮助。

    1、抛出问题

    1.1 星球典型问题

    在这里插入图片描述

    1.2 社区典型问题

    在这里插入图片描述

    1.3 QQ群典型问题

    关系型数据库中的多表之间的关联查询,ES中有什么好的解决方案?
    如果我把关联关系的表迁移到ES中放到一个type下,文档结构除了对象之间的嵌套还有什么好的解决方案?

    2、基础认知

    2.1 关系型数据库

    关系数据库是专门为关系设计的,有如下特点

    • 可以通过主键唯一地标识每个实体(如Mysql中的行)。
    • 实体 规范化 。唯一实体的数据只存储一次,而相关实体只存储它的主键。只能在一个具体位置修改这个实体的数据。
    • 实体可以进行关联查询,可以跨实体搜索。
    • 支持ACID特性,即:单个实体的变化是 原子的 , 一致的 , 隔离的 , 和 持久的 。
    • 大多数关系数据库支持跨多个实体的 ACID 事务。

    关系型数据库的缺陷

    • 第一:全文检索有限的支持能力。 这点,postgresql已部分支持,但相对有限。
    • 第二:多表关联查询的耗时很长,甚至不可用。之前系统开发中使用过Mysql8个表做关联查询,一次查询等待十分钟+,基本不可用。

    2.2 Elasticsearch

    Elasticsearch ,和大多数 NoSQL 数据库类似,是扁平化的。索引是独立文档的集合体。 文档是否匹配搜索请求取决于它是否包含所有的所需信息和关联程度。

    Elasticsearch 中单个文档的数据变更是满足ACID的, 而涉及多个文档时则不支持事务。当一个事务部分失败时,无法回滚索引数据到前一个状态。

    扁平化有以下优势

    1. 索引过程是快速和无锁的。
    2. 搜索过程是快速和无锁的。
    3. 因为每个文档相互都是独立的,大规模数据可以在多个节点上进行分布。

    2.3 Mysql VS Elasticsearch

    • mysql才擅长关系管理,而ES擅长的是检索。

    • Medcl也曾强调:“如果可能,尽量在设计时使用扁平的文档模型。” Elasticsearch的关联存储、检索、聚合操作势必会有非常大的性能开销。
      在这里插入图片描述

    3 Elasticsearch关联关系如何存储

    关联关系仍然非常重要。某些时候,我们需要缩小扁平化和现实世界关系模型的差异。
    以下四种常用的方法,用来在 Elasticsearch 中进行关联数据的管理:

    3.1 应用端关联

    这是普遍使用的技术,即在应用接口层面来处理关联关系。
    针对星球问题实践,

    1. 存储层面:独立两个索引存储。
    2. 实际业务层面分两次请求:

    第一次查询返回:Top5中文姓名和成绩;
    根据第一次查询的结果,第二次查询返回:Top5中文姓名和英文姓名;

    将第一次查询结果和第二次查询结果组合后,返回给用户。
    即:实际业务层面是进行了两次查询,统一返回给用户。用户是无感知的。

    适用场景数据量少的业务场景。
    优点:数据量少时,用户体验好。
    缺点:数据量大,两次查询耗时肯定会比较长,影响用户体验。

    引申场景:关系型数据库和ES 结合,各取所长。将关系型数据库全量同步到 ES 存储,不做冗余存储。
    如前所述:ES 擅长的是检索,而 MySQL 才擅长关系管理。所以可以考虑二者结合,使用 ES 多索引建立相同的别名,针对别名检索到对应 ID 后再回 MySQL 查询,业务层面通过关联 ID join 出需要的数据。

    3.2 宽表冗余存储

    对应于官方文档中的“Data denormalization”,官方直接翻译为:“非规范化你的数据”,总感觉规范化是什么鬼,不好理解。
    通俗解释就是:冗余存储,对每个文档保持一定数量的冗余数据可以在需要访问时避免进行关联。

    这点通过logstash 同步关联数据到ES时,通常会建议:先通过视图对Mysql数据做好多表关联,然后同步视图数据到ES。此处的视图就是宽表。

    针对星球问题实践:姓名、英文名、成绩两张表合为一张表存储。

    适用场景:一对多或者多对多关联。

    优点:速度快。因为每个文档都包含了所需的所有信息,当这些信息需要在查询进行匹配时,并不需要进行昂贵的关联操作。

    缺点:索引更新或删除数据,应用程序不得不处理宽表的冗余数据;
    由于冗余存储,导致某些搜索和聚合操作可能无法按照预期工作。

    3.3 嵌套文档(Nested)存储

    Nested类型是ES Mapping定义的集合类型之一,它是比object类型更NB的支持独立检索的类型。
    举例:有一个文档描述了一个帖子和一个包含帖子上所有评论的内部对象评论。可以借助 Nested 实现。

    实践注意1:当使用嵌套文档时,使用通用的查询方式是无法访问到的,必须使用合适的查询方式(nested query、nested filter、nested facet等),很多场景下,使用嵌套文档的复杂度在于索引阶段对关联关系的组织拼装。

    推荐实践:https://blog.csdn.net/laoyang360/article/details/82950393

    实践注意2

    index.mapping.nested_fields.limit 缺省值是50。即:一个索引中最大允许拥有50个nested类型的数据。
    index.mapping.nested_objects.limit 缺省值是10000。即:1个文档中所有nested类型json对象数据的总量是10000。
    

    适用场景:1 对少量,子文档偶尔更新、查询频繁的场景。
    如果需要索引对象数组并保持数组中每个对象的独立性,则应使用嵌套 Nested 数据类型而不是对象 Oject 数据类型。

    优点:nested文档可以将父子关系的两部分数据(举例:博客+评论)关联起来,可以基于nested类型做任何的查询。
    缺点:查询相对较慢,更新子文档需要更新整篇文档。

    3.4 父子文档存储

    注意:6.X之前的版本的父子文档存储在相同索引的不同type中。而6.X之上的版本,单索引下已不存在多type的概念。父子文档Join的都是基于相同索引相同type实现的。

    Join类型是ES Mapping定义的类型之一,用于在同一索引的文档中创建父/子关系。 关系部分定义文档中的一组可能关系,每个关系是父名称和子名称。

    实践参考:https://blog.csdn.net/laoyang360/article/details/79774481

    适用场景:子文档数据量要明显多于父文档的数据量,存在1 对多量的关系;子文档更新频繁的场景。

    举例:1 个产品和供应商之间是1对N的关联关系。
    当使用父子文档时,使用has_child 或者has_parent做父子关联查询。

    优点:父子文档可独立更新。
    缺点:维护Join关系需要占据部分内存,查询较Nested更耗资源。

    4 小结

    在这里插入图片描述

    1. 在Elasticsearch开发实战中对于多表关联的设计要突破关系型数据库设计的思维定式
    2. 不建议在es做join操作,parent-child能实现部分功能,但是它的开销比较大,如果可能,尽量在设计时使用扁平的文档模型。
    3. 尽量将业务转化为没有关联关系的文档形式,在文档建模处多下功夫,以提升检索效率。
    4. Nested&Join父子文选型必须考虑性能问题。 nested 类型检索使得检索效率慢几倍,父子Join 类型检索会使得检索效率慢几百倍。

    以上内容,实际官方文档都有明确的描述。我把内容加上自己的理解,作了精炼和解读。
    再次强调:第一手资料的重要性。但本着“再显而易见的道理,也有N多人不知道”的原则,一定要读英文官方文档,加深认知理解。

    Elasticsearch多表关联你是如何做的呢?欢迎留言写下您的思考。

    参考:
    [1] https://www.elastic.co/guide/en/elasticsearch/guide/current/relations.html
    [2] rockybean 教程

    在这里插入图片描述
    铭毅天下——Elasticsearch基础、进阶、实战第一公众号

    展开全文
  • EF多表关联数据更新

    万次阅读 2016-12-08 13:43:45
    本篇主要讲述多表关联数据的更新,以及如何使用原生SQL。 文章提纲 多表关联数据更新 如何使用原生SQL 总结 多表关联数据更新 我们在第四篇文章已经讲过数据的更新了,不过那个是针对单表结构...

    本篇是第一阶段的完结篇。

    学完这篇后,你应该可以利用MVC进行完整项目的开发了。

    本篇主要讲述多表关联数据的更新,以及如何使用原生SQL。

    文章提纲

    • 多表关联数据更新
    • 如何使用原生SQL
    • 总结

    多表关联数据更新

    我们在第四篇文章已经讲过数据的更新了,不过那个是针对单表结构的更新。

    这次我们讲下使用EF进行关联数据的更新。

    关联数据更新有两种情况:

    1.一对多

    2.多对多

    第一种情况关联表有主外键关联,只要简单的更新外键值就可以了(相当于更新单表),我们主要讲解第二种多对多的情况。

    使用之前很熟悉的模型:

    我们定义一个场景:    

    一个用户可以有任意多个角色,一个角色可以有任意多个用户。

    我们接下来完成下面操作:

    编辑某个用户时,显示该用户的角色进行编辑。

    即 更新某个用户(SysUser表)及其相关的角色(SysUserRole表)。

     

    详细步骤:

    1.先添加一个ViewModel, 用来表示角色是否分配给某个用户。

    2.打开UserRoleController,添加一个Edit的Action用来显示编辑页面。

    有两点说明一下:

    a.我们沿用上一篇文章的模型,多了一个SysDepartment,实际模型如下:

     

    b.PopulateAssigenedRoleData将特定用户下选中的角色标记出来。

     

    3.打开Views\UserRole\Index.cshtml, 增加一个编辑按钮

     

    4.再根据Edit Action自动生成Edit View

    修改相关内容,主要是两点:

    a.部门

    b.角色

    角色是通过一组checkbox来显示的。

    Checkbox显示数据库中所有角色,已分配给用户的会显示选中状态。

    通过勾选checkbox的方式来实现用户角色的更新。

    说明

    角色少这样弄没问题,如果多的话经典的做法,可以用两个listbox,中间用箭头将左右两边的选项移动。本篇文章主要说明关联表的更新,后续文章我们会提供更好的做法的示例。

    运行下Index页面。

    进入编辑页面。

    这样编辑的显示功能就已经完成了。

    可以看到,用一组checkbox表示roles是否选中。

     

    5.最后再完成HttpPost的Edit功能。

    首先更新SysUser表:

    用model binder中的值更新entity: userToUpdate.

    可以看到,我们使用了白名单指定数据库中需要更新的字段。

    TryUpdateModel(userToUpdate,"",

    new string[] {"LoginName","Email","Password","CreateDate","SysDepartmentID"})

     

    再更新SysUserRole表:

    将数据库中值和编辑后的值进行比对,基本逻辑是:

    如果被选中了,原来没有的要添加;

    如果没被选中,原来有的要删除。

    UpdateUserRoles(selectedRoles, userToUpdate);

     

     

    注意在UpdateUserRoles里,我新建了一个连接

    using (AccountContext db2=new AccountContext())

    如果用之前的db会报如下错误:

    已有打开的与此 Command 相关联的 DataReader,必须首先将它关闭。

     

    重新运行下Index, 如下一组图,这时我们看到角色编辑已经起作用了。

    至此,多表更新的示例就介绍到这,其他情况相信你可以举一反三自己推导出来做法。

     

     

    使用原生SQL

    使用EF的一个优点就是自动帮我们生成SQL,这在常规情况下很方便,但有些情况下用EF却不适合。

    例如我们上面更新SysUserRole这张表时,每次增减一条数据,要循环很多次。

    另外还有些特别复杂的语句,利用EF很难生成。

    EF提供一组方法用来执行原生的SQL.

    有以下三种:

    1.DbSet.SqlQuery

    2.Database.SqlQuery

    3.Database.ExecuteSqlCommand

    这三种有啥区别呢?我们来看例子。

    对三种形式我们各举一例。

    例子1:DbSet.SqlQuery查询并返回Entities

    我们打开Controllers\AccountController.cs做实验

    找到Details方法

    将注释的部分改成方框部分即可。

    方框中的和注释掉的内容SysUser sysUser=db.SysUsers.Find(id)完全一样。

    前端显示效果不变:

     

    注意两点:

    1.构造带参数的SQL语句(养成好习惯,防止SQL注入,总是用带参数的SQL语句)

    2.此处使用的是DbSet<TEntity>执行SQL方法,返回的直接是Entity, 和LINQ查询一样。如果暂时不熟悉LINQ,用这种方法替换(作为一个过渡),可以让你快速的使用起新框架。

    这种情况有一些缺陷,例如

    SELECT LoginName as UserName,* FROM [dbo].[SysUser] WHERE ID=@id

    大家可以看到我添加了LoginName as UserName,这是因为Model中用了Column Attribute,数据库中存的字段是LoginName

    这样我如果不转换,model就会找不到匹配的字段而出错,而如果用db.SysUsers.Find(id) 就可以智能转换。

     

    例子2 Database.SqlQuery 返回其他类型

    string query = "select loginName from SysUser";

    var names=db.Database.SqlQuery<string>( query).ToList();

    以上会返回一个System.Collections.Generic.List<string>类型。

    这种方式和第一种情况最大的区别就是返回non-entity 类型。

    我们可以根据需要,自己构建需要的类型。

    我们也可以自定义一个entity type让它返回,例如类似我们上一个例子:

    SysUser sysUser = db. Database.SqlQuery(query, paras).SingleOrDefault();

    这样也可以返回entity, 但要注意,这种方式将不会被context track, 返回后就没关系了,如果我们在View中用类似于Model.XXX导航属性获取其他关联数据就会报错。例如@foreach (var item in Model.SysUserRoles),这种情况下会报Model为null的错误。

     

    例子3:Database.ExecuteSqlCommand执行更新语句

    最后一个是更新的,直接看示例就明白了:

    context.Database.ExecuteSqlCommand("UPDATE dbo.Posts SET Rating = 5 WHERE Author = @author", new SqlParameter("@author", userSuppliedAuthor));

     

    最后提下执行存储过程,也类似,我就不多说了,如下MSDN(https://msdn.microsoft.com/en-us/data/jj592907)截图。

     

    原生SQL使用总结

    原生SQL执行查询:

    需要返回实体模型,使用DbSet.SqlQuery (context会跟踪,等效于LINQ方式)

    需要返回其他类型,使用Database.SqlQuery

    原生SQL执行更新:

    使用Database.ExecuteSqlCommand

     

    至此,本系列文章的第一阶段(1~10)就结束了,下一阶段再见。

    感谢支持,祝学习进步!

    P.S. 方便大家观看,列出系列文章地址:

     

     

    展开全文
  • 1. 首先,什么是视图,通俗的讲 在实际的数据库中,每一张会有很个字段,但是不同的用户只想了解自己想了解的字段,对于其他的字段并不感兴趣,这时候使用视图可以把自己想要的一些字段再封装成一张表,这样每次...

    一.视图

    1. 首先,什么是视图,通俗的讲 在实际的数据库中,每一张表会有很多个字段,但是不同的用户只想了解自己想了解的字段,对于其他的字段并不感兴趣,这时候使用视图可以把自己想要的一些字段再封装成一张表,这样每次特定用户只需要访问这张封装成的表即可了解自己想知道的字段。    再说的专业一点,视图是对SQL语句的封装,这个说法在下面进行解释

    2. 为什么说 视图是对SQL语句的封装呢?这是因为,我们在数据库中建立的一张张表会实际存储到存储设备上,比如磁盘,我们每次使用select语句,实际上就是在访问内存中的表,但是视图并不是,视图保存的并不是数据,而是select语句,每次从视图中读取数据的时候,相当于是在内部执行select语句并创建出一张临时表

    3.  视图的优点:(1)视图不需要保存实际数据,节省存储空间(2)可以将频繁使用的select语句保存成视图,这样就不用每次都书写复杂的SQL了

    那么我们通过实际的例子进行说明关于视图的一些操作,下图是我们用到的叫做product的表

    4. 视图的创建

    CREATE VIEW ProductSum(product_type,product_sum) 创建一个叫做ProductSum的视图,其中有两个字段
    AS                                                                                 必须写的关键字
    select product_type,COUNT(*)                                        从Product中抽取出两个字段
    from product

    GROUP BY product_type;

    注意事项:(1)AS必须写 (2)在从其他表抽取数据构成视图的时候可以使用where ,group by ,having

    5. 视图的查询----》同查表一致

    select * from ProductSum; 查询结果如下

    在执行这条查询时,数据库会先执行定义视图的select语句,再执行select * from

    6.  视图的限制:(1)不要使用order by定义视图 

        (2)对视图进行更新:通过上面的说明,我们知道,视图实际上是对SQL语句的封装,以上面的例子来说,ProductSum来自于表product,那么当表中的数据发生变化时,ProductSum中的数据也会跟着发生变化,因为视图是根据表通过select语句得到的   那么现在进入正题,如果我们对视图使用insert,update,delete语句时会发生什么呢 实际上,对视图进行操作时会连带着更新相应的表,但是会对生成视图的select语句有一定的限制  a. 未使用distinct 去重   b.from中只有一张表   c.未使用group by 以及having子句

    7. 视图的删除  --》drop view ProductSum;

     

    二.子查询

     1.  首先我们需要知道,什么是子查询呢,子查询就是将用来定义视图的select语句直接用于from语句中,通过下面的例子 进行说明

    select * from ProductSum;结果是

    当我们使用子查询的时候

    我们把用作定义视图使用的select语句,直接放到from 语句 中 并且通过as关键字 指定子查询的名称,但由于该名称是一次性的,所以当本次查询结束之后立刻消失不会保存起来

     

    三.标量子查询

    1. 标量子查询就是 返回值只能有一行一列的子查询

    2. 我们想查询销售单价大于全部商品平均售价的商品 

    select product_id,product_name,sale_price
    from product
    where sale_price>(select AVG(sale_price )

                         from product);   结果如下

    在执行这条语句时,数据库会先执行 select AVG(sale_price )  from product返回所有商品的平均价格 2097.5

    然后在执行剩下的SQL语句时 实际上就成了 执行 

    select product_id,product_name,sale_price  

    from product  

    where sale_price>2097.5

    注意事项:(1)标量子查询绝对不能返回多个结果 (2)标量子查询可以出现在select,group by,having ,ordder by子句中

     

    四.关联子查询

    1. 在这里 我们先抛出一个问题,在上面我们提到了 查询售价高于所有商品平均价格的商品信息,那么如果我们想要了解到各个商品种类中高于该商品种类的平均销售单价的商品信息

    2. 这时候就需要关联子查询了

    select product_type,product_name,sale_price
    from product as p1
    where sale_price>(select AVG(sale_price) 
                       from product as p2
                        where p1.product_type=p2.product_type

                          GROUP BY product_type);

    注意事项:这里起到关键作用的就是在子查询中添加的where子句,该条件的意思时,在同一商品种类中对各个商品的销售单价和平均单价进行比较。这次作为比较对象的都是product表,因此进行了as区分, 在细分的组内进行比较时,需要使用关联子查询

     

     

     

    展开全文
  • Hibernate对视图关联删除

    千次阅读 2012-07-06 18:12:50
    Hibernate对视图关联删除 场景 业务实体是基于视图加载的,具体业务场景需要对此实体进行删除。Hibernate会有如下执行删除操作的SQL:DELETE FROM V_CPM_ATX; 这样因为视图中的具体之间存在有主/外键的约束...
  • 视图和临时的区别

    千次阅读 2019-08-03 18:34:01
    视图(view)是在基本之上建立的,本质是一条预编译的sql愈合,是为了满足某种查询要求而建立的一个...一个视图可以对应一个基本,也可以对应个基本视图是基本的抽象和在逻辑意义上建立的新关系. ...
  • mysql多表查询 3.关联查询

    千次阅读 2018-07-26 23:28:38
    mysql多表查询 3.关联查询 使用的数据库为mysql多表查询 2.建立多表数据库案例中的数据库。 1.1内连接查询 使用内连接查询,只有满足条件的结果才会显示。 1)内连接(第一种语法) select i.name,b.class,s....
  • 视图与临时

    千次阅读 2014-05-18 10:20:28
    视图与临时的概述、比较与应用场合。
  • ①,我们准备两张数据: 学生资料:StudentData ifexists(select*from sysobjects where id =OBJECT_ID('[StudentData]')andOBJECTPROPERTY(id,'IsUserTable')= 1) DROPTABLE [StudentData...
  • 视图

    千次阅读 2012-06-04 19:08:00
    也称为基本——Base Table)不同,视图是一个虚,即视图所对应的数据不进行实际存储,数据库中只存储视图的定义,对视图的数据进行操作时,系统根据视图的定义去操作与视图关联的基本视图一经定义以后...
  • 数据库基础:视图和临时

    千次阅读 2019-01-22 17:58:03
    从一个或中导出的。 2.视图的特点? (1)视图是一条预编译的SQL语句,并不保存实际数据、数据库只存储视图的定义; (2)视图不分配空间; (3)视图主要用于系统的安全、查询和效率; 3.视图的应用...
  • CITA视图

    万次阅读 2019-04-22 09:52:57
    视图 账号 视图状态是执行器执行过程中读写的对象,常见的视图状态模型有 UTXO 及账户两种。在 UTXO 模型中,由 UTXO 构成账本视图,每个交易在销毁旧有 UTXO 的同时创造新的 UTXO;在账户模型中,由账户构成世界...
  • OpenGL线程多视图的实现

    千次阅读 2012-09-02 05:19:00
    OpenGL在MFC下的多视图显示在很场合都能用到,而且表现力够强。前段时间自己需要一个类似于MAX之类的场景编辑工具,用来编辑自己正在的FPS游戏中所需要的场景。由于自己不懂美工、不会用MAX,所以在学习MAX与...
  • Oracle物化视图与物化视图日志

    万次阅读 多人点赞 2019-04-02 21:43:30
    文章目录物化视图物化视图与普通视图的区别创建一个存放person的创建一个存放person的address的初始化数据创建物化视图的语句1.build [immediate|deferred]2.refresh [fast|complete|force] 视图刷新的方式:3.MV...
  • 视图的建立需要依赖于单个或个普通,被依赖的普通就成为"基表"。可以就像 用 select 语句类似,在某些中选取字段和筛选条件,可以查询出数据,把这数据构成一张虚拟的,这就叫视图视图隐藏了数据的...
  • 摘要:GaussDB(DWS)是从Postgres演进过来的,像Postgres一样,如果视图引用的话,特定场景下,部分DDL操作是不能直接执行的。 背景说明 GaussDB(DWS)是从Postgres演进过来的,像Postgres一样,如果视图...
  • Android视图SurfaceView的实现原理分析

    万次阅读 多人点赞 2013-03-16 16:57:30
    在Android系统中,有一种特殊的视图,称为SurfaceView,它拥有独立的绘图表面,即它不与其宿主窗口共享同一个绘图表面。由于拥有独立的绘图表面,因此SurfaceView的UI就可以在一个独立的线程中进行绘制。又由于不会...
  • oracle 物化视图、中间的方案

    千次阅读 2019-01-13 10:46:10
    有个项目因为有比较的查询汇总,考虑到速度,所以使用了物化视图。简单的把用到的给整理了下。 先看简单创建语句: create materialized view mv_materialized_test refresh force on demand start with sysdate...
  • SQL视图

    千次阅读 2016-09-17 10:16:21
    视图是虚拟的。与包含的数据不一样,视图只包含使用时动态检索的数据查询。作为视图,他不包含任何列或数据,包含的只是一个查询。 为什么使用视图? 1:重用sql语句。 2:简化复杂的sql操作。在编写查询后,...
  • VF中之间关联

    千次阅读 2010-05-20 21:01:00
    VF中之间关联,是指在两个中建立关联联系。命令是:SET RELATION TO eExpression1 INTO cTableAlias参数:eExpression1指定用来在父和子之间建立关系的关系表达式。关系表达式通常是子主控索引的索引...
  • MySQL视图

    千次阅读 2018-07-24 18:25:44
    MySQL视图 视图(view)是一种虚拟存在的,是一个逻辑,本身并不包含数据。作为一个select语句保存...简单:使用视图的用户完全不需要关心后面对应的的结构、关联条件和筛选条件,对用户来说已经是过滤好的复...
  • 表视图样式和扩展视图 原文链接 表视图根据特殊的需求可以创建不通的样式。另外,UIKit框架提供一些标准样式来绘制各个单元格。 表视图样式: 表视图主要分为两种样式:plain类型和grouped类型。从呈现形式上...
  • ,该函数遍历文档模板,对每个文档进行匹配,若该文件已经在某个文档中打开,则会激活该文档视图,否则用匹配的文档模板,调用下一个打开函数,其原型为: [cpp] view plain copy print ? CDocument* ...
  • 视图:就是一个或者的一个映射,一般只查询使用。比如你想要的数据存在两个表里,但你查询时不想每次都写关联,那么你创建一个视图,以后只查询这个视图就可以(查询时视图与查询表语法一样)。 触发器:...
  • Qt 之图形视图框架

    万次阅读 多人点赞 2016-07-20 16:59:13
    简述图形视图(Graphics View)提供了一个用于管理和交互大量自定义的二维图形对象(Item),以及一个支持缩放和旋转操作的视图部件用于显示这些视图项。框架包括一个事件传播架构,支持scene中的items进行精确的双...
  • 数据库 视图基础概念

    万次阅读 2019-01-19 11:06:12
    视图是从一个或是导出的视图不同,视图是一个虚,即视图所对应的数据不进行实际存储,数据库中指存储视图的定义,在对视图的数据进行操作时,系统根据视图的定义去操作与视图关联的基本。...
  • Oracle中常用视图

    千次阅读 2016-12-21 16:45:55
    1.dba_开头   dba_users 数据库用户信息   dba_segments 段信息   dba_extents 数据区信息   dba_objects 数据库对象信息   dba_tablespaces 数据库空间信息   dba_data_fil
  • Java 数据库的视图

    千次阅读 2012-06-04 16:03:39
    视图是从一个或(或视图)导出的视图是数据库的用户使用数据库的观点。例如,对于一个学校,其学生的情况存于数据库的一个或中,而作为学校的不同职能部门,所关心的学生数据的内容是不同的。即使是...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 104,921
精华内容 41,968
关键字:

视图用来做多表关联