精华内容
下载资源
问答
  • Entity Framework多视图条件查询、排序

    千次阅读 2017-04-26 22:42:29
    Entity Framework多视图条件查询、排序

          Entity Framework在C#中常常用于底层和数据库交互,也就是DAL层。而Entity Framework中与数据库交互时底层与数据库通讯的重要的容器就是DbContext。

        而使用DbContext对数据库联表查询是最常见的操作。这里介绍多视图联合查询的加条件,等一些内容

    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Linq.Expressions;
    using System.Text;
    
    namespace RBIM.COMMON
    {
        public static class PredicateBuilder
        {
    
            /// <summary>
            /// 机关函数应用True时:单个AND有效,多个AND有效;单个OR无效,多个OR无效;混应时写在AND后的OR有效  
            /// </summary>
            /// <typeparam name="T"></typeparam>
            /// <returns></returns>
            public static Expression<Func<T, bool>> True<T>() { return f => true; }
    
            /// <summary>
            /// 机关函数应用False时:单个AND无效,多个AND无效;单个OR有效,多个OR有效;混应时写在OR后面的AND有效  
            /// </summary>
            /// <typeparam name="T"></typeparam>
            /// <returns></returns>
            public static Expression<Func<T, bool>> False<T>() { return f => false; }
    
            public static Expression<Func<T, bool>> Or<T>(this Expression<Func<T, bool>> expr1,
                                                                Expression<Func<T, bool>> expr2)
            {
                var invokedExpr = Expression.Invoke(expr2, expr1.Parameters.Cast<Expression>());
                return Expression.Lambda<Func<T, bool>>
                      (Expression.Or(expr1.Body, invokedExpr), expr1.Parameters);
            }
    
            public static Expression<Func<T, bool>> And<T>(this Expression<Func<T, bool>> expr1,
                                                                 Expression<Func<T, bool>> expr2)
            {
                var invokedExpr = Expression.Invoke(expr2, expr1.Parameters.Cast<Expression>());
                return Expression.Lambda<Func<T, bool>>
                      (Expression.And(expr1.Body, invokedExpr), expr1.Parameters);
            }
        }
    }
    
    数据接口实现层:

    /// <summary>
            ///获取所有数据TransducerConfiguration
            /// </summary>
            public IList<FindStressDetectionByProjectKey> GetStressDetectionInfoList(Dictionary<string, string> dicparams)
            {
                try
                {
                    Expression<Func<FindStressDetectionByProjectKey, bool>> searchPredicate = PredicateBuilder.True<FindStressDetectionByProjectKey>();
                    foreach (string key in dicparams.Keys)
                    {
                        string condition = string.Empty;
                        switch (key.ToLower())
                        {
                            case "projectkey": //case自己扩展  
                                condition = dicparams[key];
                                searchPredicate = searchPredicate.And(c => c.ProjectKey.ToString() == condition);
                                break;
                            case "smsid":
                                condition = dicparams[key];
                                searchPredicate = searchPredicate.And(c => c.Smsid == condition);
                                break;
                            case "tdh":
                                condition = dicparams[key];
                                searchPredicate = searchPredicate.And(c => c.TDH == condition);
                                break;
                            default:
                                break;
                        }
                    }
                    return _dbContext.FindStressDetectionByProjectKey.Where(searchPredicate.Compile()).OrderByDescending(c => c.ID).ToList();
                }
                catch (EntityException e)
                {
                    throw e.InnerException;
                }
     而UI层调用时:
    Dictionary<string, string> dicparams = new Dictionary<string, string>();
    IList list = HardwareServiceFacade.hardwareService.SoapService.GetStressDetectionInfoList(dicparams).ToList();

    
    

    
    


    展开全文
  •   在写视图的时候,如果想要对查询的数据排序,直接在后面加order by...会出错,如果在前面加上top 10,就会没问题。...所以一般想要对视图查询进行排序,一定要select * from vw_mmm order by......

                    

     

    在写视图的时候,如果想要对查询的数据排序,直接在后面加order by...会出错,如果在前面加上top 10,就会没问题。

    所以一般想要对视图的查询进行排序,一定要select * from vw_mmm order by...

    展开全文
  • 目录 一、定义视图 1、建立视图 2、删除视图 二、查询视图 ...WITH CHECK OPTION:加上这个语句后即对视图的修改需要符合定义视图时子查询中的条件表达式。 例1:单个表上的视图 CREATE VIE...

    目录

    一、定义视图

    1、建立视图

    2、删除视图

    二、查询视图

    三、更新视图

    四、视图的作用


    一、定义视图

    1、建立视图

    语法:CREATE VIEW 视图名 【列名】... AS 子查询 【WITH CHECK OPTION】

    WITH CHECK OPTION:加上这个语句后即对视图的修改需要符合定义视图时子查询中的条件表达式。

    例1:单个表上的视图

    CREATE VIEW IS_Student AS SELECT Sno, Sname, Sage FROM Student WHERE Sdept='IS';

    解释:建立信息系学生的视图。

    例2:多个表上的视图

    CREATE VIEW IS_S1(Sno, Sname, Grade) AS SELECT Student.Sno, Sname, Grade FROM Student, SC WHERE Sdept='IS' AND Student.Sno=SC.Sno AND SC.Cno='1';

    解释:建立信息系选修了1号课程的学生的视图。

    例3:在视图上建立视图

    CREATE VIEW IS_S2 AS SELECT Sno, Sname, Grade FROM IS_S1 WHERE Grade>=90;

    解释:建立信息系选修1号课程且成绩在90分以上的学生视图。

    例4:带虚拟列的视图(带表达式的视图)

    CREATE VIEW BT_S(Sno, Sname, Sbirth) AS SELECT Sno, Sname, 2014-Sage FROM Student;

    解释:反映学生出生年份的视图。

    例5:分组视图

    CREATE VIEW S_G(Sno, Gavg) AS SELECT Sno, AVG(Grade) FROM SC GROUP BY Sno;

    解释:将学生的学号及平均成绩定义为一个视图。

    2、删除视图

    语法:DROP VIEW 视图名;

    例:DROP VIEW S_G;

    二、查询视图

    视图定义后就可以向对基本表一样对视图进行查询了。

    例1:SELECT Sno, Sage FROM IS_Student WHERE Sage<20;

    解释:使用刚刚定义的视图IS_Student进行查询年龄小于20岁的学生。

    例2:SELECT * FROM IS_S1;

    解释:查询刚刚定义的视图IS_S1。

    三、更新视图

    由于视图是不实际存在的虚表,因此对视图的更新最终要转换为对基本表的更新。

    例:UPDATE IS_Student SET Sname='lili' WHERE Sno='201215125';

    解释:将信息系学生视图IS_Student中学号为“201215125”的学生姓名改为“lili”。

    四、视图的作用

          1) 视图能够简化用户的操作

          2) 视图使用户能以多种角度看待同一数据

          3) 视图对重构数据库提供了一定程度上的逻辑独立性

          4) 视图能够对机密数据提供安全保护

          5) 适当利用视图可以更清晰地表达查询

    展开全文
  • MYSQL视图查询

    千次阅读 2019-03-26 13:48:17
    最近在优化项目页面响应时间,发现一处sql查询结构简单却非常慢,点进去发现是从视图进行查询的,刚开始不知道为什么,后来查询才明白原因,记录一下。 视图定义在有些时候方便很多,但是有些复杂情况定义就不适合。...

    本文转自http://wangyuanzju.blog.163.com/blog/static/130292007714102859807/

    最近在优化项目页面响应时间,发现一处sql查询结构简单却非常慢,点进去发现是从视图进行查询的,刚开始不知道为什么,后来查询才明白原因,记录一下。

    视图定义在有些时候方便很多,但是有些复杂情况定义就不适合。因为mysql先执行视图的查询,得到的结果是很大范围的,然后从中在进行条件筛选,所以导致效率会很差。
    以下内容为从博客复制。

    视图是MySQL 5.0中增加的三大新功能之一(另外两个是存储过程与触发器),也是一般稍微“高级”一点的数据库所必需要有的功能。MySQL在定义视图上没什么限制,基本上所有的查询都可定义为视图,并且也支持可更新视图(当然只有在视图和行列与基础表的行列之间存在一一对应关系时才能更新),因此从功能上说MySQL的视图功能已经很完善了。

    然而若要在应用中使用视图,还需要了解处理视图时的性能,而MySQL在这方面问题是比较大的,需要特别注意。首先要知道MySQL在处理视图时有两种算法,分别称为MERGE和TEMPTABLE。在执行"CREATE VIEW"语句时可以指定使用哪种算法。所谓MERGE是指在处理涉及到视图的操作时,将对视图的操作根据视图的定义进行展开,有点类似于C语言中的宏展开。比如设有以下的表(类似于博客中的评论):
    CREATE TABLE comment (
    id int(11) NOT NULL,
    user_id int(11) default NULL,
    content varchar(255) default NULL,
    PRIMARY KEY (id),
    KEY idx_comment_uid (user_id)
    ) ENGINE=InnoDB;
    假设user_id < 10000的用户为VIP用户,我们可以这样创建一个视图来表示VIP用户的评论:
    CREATE VIEW vip_comment AS SELECT * FROM comment WHERE user_id < 10000;
    这时我们在操作vip_comment视图时使用的就是MERGE算法。如:
    mysql > EXPLAIN EXTENDED SELECT count(*) FROM vip_comment WHERE user_id < 0;
    ±—±------------±--------±------±----------------±----------------±--------±-----±-----±-------------------------+
    | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
    ±—±------------±--------±------±----------------±----------------±--------±-----±-----±-------------------------+
    | 1 | SIMPLE | comment | range | idx_comment_uid | idx_comment_uid | 5 | NULL | 10 | Using where; Using index |
    ±—±------------±--------±------±----------------±----------------±--------±-----±-----±-------------------------+
    mysql> show warnings;
    ±------±-----±--------------------------------------------------------------------------------------------------------------------------------------+
    | Level | Code | Message |
    ±------±-----±--------------------------------------------------------------------------------------------------------------------------------------+
    | Note | 1003 | select count(0) AS count(*) from test.comment where ((test.comment.user_id < 0) and (test.comment.user_id < 10000)) |
    ±------±-----±--------------------------------------------------------------------------------------------------------------------------------------+
    可以看到,对vip_comment的操作已经被扩展为对comment表的操作。

    一般来说在能够使用MERGE算法的时候MySQL处理视图上没什么性能问题,但并非在任何时候都能使用MERGE算法。事实上,只要视图的定义稍稍有点复杂,MySQL就没办法使用MERGE算法了。准确的说,只要视图定义中使用了以下SQL构造块就无法使用MERGE算法:

    聚集函数
    DISTINCT
    GROUP BY
    HAVING
    集合操作(在MySQL中只有UNION, UNION ALL,没有EXCEPT和INTERSECT)
    子查询
    确实,在视图定义比较复杂的情况下,要对视图操作进行有效的优化是非常困难的。因此在这个时候,MySQL使用了一种以不变应万变的方法,即先执行视图定义,将其结果使用临时表保存起来,这样后续对视图的操作就转化为对临时表的操作。不能不说从单从软件设计的角度看,这样的方法非常的优雅,然而从性能角度,这一方法也是非常的差。

    比如我们希望使用如下的视图来表示每个用户的评论数,即:
    CREATE VIEW comment_count AS SELECT user_id, count() AS count FROM comment GROUP BY user_id;
    使用这个视图的时候,我们可能心里有个小算盘。目前我们先用这个视图顶着,如果性能确实有问题,那我们就再来搞一张comment_count的表,其中就记下来每个用户的评论数。而我们现在先用这个视图是为了将来要是改的话会方便点(这也是视图–即教科书中所谓的外模式–这个东西存在的主要原因之一,另一主要原因是便于权限控制)。但是遇到了MySQL这个蠢货,我们的算盘铁定会失败。
    我们来看一下指定user_id从comment_count选取记录时的执行策略:
    mysql> explain select count(
    ) from comment_count where user_id = 90;
    ±—±------------±-----------±------±--------------±----------------±--------±-----±-------±------------+
    | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
    ±—±------------±-----------±------±--------------±----------------±--------±-----±-------±------------+
    | 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 101 | Using where |
    | 2 | DERIVED | comment | index | NULL | idx_comment_uid | 5 | NULL | 524833 | Using index |
    ±—±------------±-----------±------±--------------±----------------±--------±-----±-------±------------+
    2 rows in set (4.18 sec)
    可以看出,MySQL首先是先执行comment_count的视图定义,将结果存储在临时表中(即DERIVED),然后再扫描这一临时表,选择出满足"user_id = 90"的那一条记录。这样,虽然我们最终只需要统计90号用户的评论数,并且comment表的user_id字段上也有索引,MySQL也会扫描整个comment表,并按user_id分组计算出所有用户的评论数。一般来说,这铁定会使你的系统玩完。这里面还要注意的是即使在进行EXPLAIN时,视图的物化也是要先执行的,因此若评论很多的话EXPLAIN也是一样的慢。
    这个问题的根源是MySQL的查询优化本来就存在很多问题。对于上述的查询,要达到比较好的优化效果在数据库中一般是如下处理的:
    1、将对视图的操作转化为FROM子句中的子查询:
    select * from (select user_id, count() as count from comment group by user_id) as comment_count where user_id = 90;
    2、子查询提升。因为子查询中使用了group by,因此先将外面的条件作为提升后的having条件
    select user_id, count(
    ) as count from comment group by user_id having user_id = 90;
    3、由于having条件中不涉及聚集函数,转化为where条件
    select user_id, count() as count from comment where user_id = 90 group by user_id;
    4、由于指定where条件后,user_id已经是一个常数,根据常数group by没意义,因此去掉group by
    select user_id, count(
    ) as count from comment where user_id = 90;
    一般从概念上要经过这四步转化,才能得到最后的优化语句。除第4步无法根据EXPLAIN输出和查询性能判断出MySQL是否进行这一优化外,前3类优化MySQL都不会进行。因此,MySQL要能够有效的处理上述查询还有很长的路要走。

    PS: 相对来说PostgreSQL的查询优化能力就强得多,上面的查询在PostgreSQL中就能够产生上述优化后的最终执行计划。PostgreSQL比较关注查询优化估计与PostgreSQL的学院派风格或PostgreSQL中的rule system有关。

    展开全文
  • Oracle 查询视图

    千次阅读 2019-03-18 21:48:18
    视图查询视图创建成果后,可以视图中检索数据,这点和从表中检索数据一样。 还可以查询视图的全部信息和指定的数据行和列。 SELECT * FROM salvu50; desc 视图名称 查询表结构与视图结构写法一致,如下所示: ...
  • 由于技术的原因, 这个实现必须用视图 ...视图查询不加任务条件 ,秒过的。 加了一个条件,要3分钟。 加的这个where条件视图中就是个文本,未做任何计算。 请问有什么优化的方案? 数据量也才2W左右。
  • //把数据库导出到脚本文件 mysqldump -uroot -p1234 --databases abc > d:/a/abc.sql //--...Select 字段 From 表名where 条件 and 条件 or 条件  Update tabletableName set .. Where 条件 Delete from ta
  • 我现在需要创建一个视图A,视图里面是三个视图BCD,根据一个页面传来的值判断不同的值查询不同的视图,这个值不少表中的字段。语法该怎么写?大神们帮帮忙啊!!
  • 最终,我先将四张表某些字段连接成一个视图,然后再用sql语句去该视图查询,才得到了题目所需要的信息。   经过这次练习,真的学到了很多,之前一直以为自己对于数据库SQL语句已经很熟练了,以为这次实验应该会...
  • 视图和子查询

    千次阅读 2017-07-26 18:30:53
    视图视图可以理解成一张表。但它不保存在计算机的存储设备中,也不保存数据到任何地方,事实上,他保存的是select语句。 语法创建语法:create view view_name(col_name1,...) as select 子句;删除的语法:drop...
  • JPA的视图查询

    万次阅读 热门讨论 2012-12-27 14:43:33
    这也是为什么很多人使用JPA想通过实体映射数据库内建视图的方式进行查询,却始终映射不成功的症结所在。 )     package net.csdn.blog.chaijunkun.dao; import java.util.List; import javax....
  • 索引视图条件

    2013-05-31 21:01:17
    索引视图是有很多要求的 create view dbo.test_view with schemabinding -- 架构绑定 as select * from test go  在对视图创建聚集索引之前,该视图必须符合下列要求: 当执行 CREATE VIEW ...
  • 一个视图在同等查询条件下 第一次查询的速度与第二次查询的速度是否有区别 3.一个索引视图与一个普通视图在不做其他运算的情况下 即select * from 视图 这种情况 效率是否有区别
  • 允许进行DML操作的视图条件

    千次阅读 2014-06-05 08:01:44
    视图可以屏蔽某些基表的信息,或是join多个基表组成一个复杂查询视图本身也是可以进行DML操作,但受一些条件的限制。 首先我们看下官方文档对视图进行DML操作的要求说明: The following notes apply to ...
  • 查询视图时 ,带where 条件速度过慢

    千次阅读 2019-05-29 15:29:45
    今天遇到这样一个情况,通过视图查询一些字段不带where语句时很快。SQL如下 select * ,ROW_NUMBER () OVER (ORDER BY tabs.recognisedmaori DESC) AS pos from( SELECT vp.projectid id, vp.projectno ...
  • SQL视图查询详解

    万次阅读 2015-12-25 19:48:53
    T-SQL查询进阶--深入浅出视图 简介     视图可以看作定义在SQL Server上的虚拟表.视图正如其名字的含义一样,是另一种查看数据的入口.常规视图本身并不存储实际的数据,而仅仅存储一个Select语句和所...
  • 视图

    2013-10-07 19:44:54
    视图简介:  视图是基于一个表或多个表或视图的逻辑表,本身不包含数据,通过它可以对表里面的数据进行查询和修改。视图基于的表称为基表。...2.用户通过简单的查询可以从复杂查询中得到结果。  3.维护数据的独立性

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 157,801
精华内容 63,120
关键字:

视图可以条件查询吗