精华内容
下载资源
问答
  • 因为大多数数据库教程都是告诉你关系数据库如何创建1:1、1:N和N:M数据库关系,但我发现很多开源产品中,并没有直接使用关系数据库关系查询、关系删除等功能,而是直接在代码中对多个表的查询结果进行...

    有人会对数据库有这样的疑问:

    因为大多数的数据库教程上都是告诉你关系数据库如何去创建1:1、1:N和N:M的数据库关系,但我发现很多开源产品中,并没有直接使用关系数据库的关系查询、关系删除等功能,而是直接在代码中对多个表的查询结果进行组合。

    这两种方式的优缺点是什么呢?为什么很多项目都选择后者呢?在一个中型以上的项目实践中,我该选择哪种方式,或是两种方式结合使用?

    我想:

    1,数据表与数据表之间有关联(Relationship)是肯定的,但是不一定要用外键(Foreign Key),为什么?外键本质是一种约束(Constraint),该约束决定了你在增删改查的时候都会有额外开销。【实际上数据库在处理外键的时候估计也是创建一个中间表根据中间表来做关联操作,完成后再删除】

    2,“对于 “N对N” 的关系,两个 Model 之间肯定是需要一张中间表的,比如 Student、Class 之间选课关系,是多对多的,肯定需要一张 Enroll 的表来维持,记录两个表的主键(Primary Key),但是不需要在数据库层加外键约束,只需要加两个索引,或作为联合主键。

    3,至于查询,尽量不用 JOIN。但是问题是我确确实实是需要知道多个表的信息。

    比如我要知道某门课(Class,已知 ID)的信息,同时还有选上该课(Enrolled)的学生信息(Student)。

    使用 JOIN ?没问题,我相信你可以写出一个很长的 JOIN 语句。

    但是,可能有的地方大概这样实现的(伪代码):

    getClassInfo(@class_id)

    {SELECT class_col1,class_col2 FROM classWHERE class.id =@class_id}

    getStudentInfo(@class_id)

    {SELECT student_col1,student_col2 FROM student WHERE student.id IN (SELECT enroll.student_id FROM enroll WHERE enroll.class_id =@class_id)}

    两种方案各有优缺。

    后者最大的一个优点是灵活,比如我们引入缓存(Caching)。

    一般来说,一个学校 class 数量不多,并且经常被查询,系统可能会引入缓存层(如 memcached、redis)来存放 class 对象。

    那么上面的 getClassInfo 其实会变为

    {

    if(memcached.has(@class_id)!=null)

    {

    returnmemcached.get(@class_id);

    }

    //查询数据库(只有 class 表),和上面的 SQL 一样

    memcached.set(@class_id,class_object);

    returnclass_object;

    }

    展开全文
  • 因为大多数数据库教程都是告诉你关系数据库如何创建1:1、1:N和N:M数据库关系,但我发现很多开源产品中,并没有直接使用关系数据库关系查询、关系删除等功能,而是直接在代码中对多个表的查询结果进行...

    有人会对数据库有这样的疑问:

    因为大多数的数据库教程上都是告诉你关系数据库如何去创建1:1、1:N和N:M的数据库关系,但我发现很多开源产品中,并没有直接使用关系数据库的关系查询、关系删除等功能,而是直接在代码中对多个表的查询结果进行组合。

    这两种方式的优缺点是什么呢?为什么很多项目都选择后者呢?在一个中型以上的项目实践中,我该选择哪种方式,或是两种方式结合使用?

    我想:

    1,数据表与数据表之间有关联(Relationship)是肯定的,但是不一定要用外键(Foreign Key),为什么?外键本质是一种约束(Constraint),该约束决定了你在增删改查的时候都会有额外开销。【实际上数据库在处理外键的时候估计也是创建一个中间表根据中间表来做关联操作,完成后再删除】

    2,“对于 “N对N” 的关系,两个 Model 之间肯定是需要一张中间表的,比如 Student、Class 之间选课关系,是多对多的,肯定需要一张 Enroll 的表来维持,记录两个表的主键(Primary Key),但是不需要在数据库层加外键约束,只需要加两个索引,或作为联合主键。

    3,至于查询,尽量不用 JOIN。但是问题是我确确实实是需要知道多个表的信息。

    比如我要知道某门课(Class,已知 ID)的信息,同时还有选上该课(Enrolled)的学生信息(Student)。

    使用 JOIN ?没问题,我相信你可以写出一个很长的 JOIN 语句。

    但是,可能有的地方大概这样实现的(伪代码):

    getClassInfo(@class_id)

    {SELECT class_col1,class_col2 FROM classWHERE class.id =@class_id}

    getStudentInfo(@class_id)

    {SELECT student_col1,student_col2 FROM student WHERE student.id IN (SELECT enroll.student_id FROM enroll WHERE enroll.class_id =@class_id)}

    两种方案各有优缺。

    后者最大的一个优点是灵活,比如我们引入缓存(Caching)。

    一般来说,一个学校 class 数量不多,并且经常被查询,系统可能会引入缓存层(如 memcached、redis)来存放 class 对象。

    那么上面的 getClassInfo 其实会变为

    {

    if(memcached.has(@class_id)!=null)

    {

    returnmemcached.get(@class_id);

    }

    //查询数据库(只有 class 表),和上面的 SQL 一样

    memcached.set(@class_id,class_object);

    returnclass_object;

    }

    展开全文
  • A,B两个表数据规模十几万,数据规模都不大,单机MySQL够用了,在单机的基础关联两表的数据,先说一个极端情况,A,B两个表都没有索引,并且关联是笛卡尔积,那关联结果会爆炸式增长,可能到亿级别,这个时候网络...

    A,B两个表数据规模十几万,数据规模都不大,单机MySQL够用了,在单机的基础上要关联两表的数据,先说一个极端情况,A,B两个表都没有索引,并且关联是笛卡尔积,那关联结果会爆炸式增长,可能到亿级别,这个时候网络IO成了瓶颈,这个时候两次十万行结果集的拉去可能远小于1次亿级别的结果集的拉取,那么将关联合并拉到service层做更快。但实际业务中一般不会有这么蠢的行为,一般关联会有连接条件,并且连接条件上会有索引,一般是有一个结果集比较小,拿到这个结果集去另一张表去关联出其它信息,如果放到service层去做,最快的方式是,先查A表,得到一个小的结果集,一次rpc,再根据结果集,拼凑出B表的查询条件,去B表查到一个结果集,再一次rpc,再把结果集拉回service层,再一次rpc,然后service层做合并,3次rpc,如果用数据库的join,关联结果拉回来,一次rpc,帮你省了两次rpc,当然数据库上做关联更快,对应到数据库就是一次blk nested loop join,这是业务常用情况。

    但是确实大多数业务都会考虑把这种合并操作放到service层,我觉得有几方面考虑:

    第一:单机数据库计算资源很贵,数据库同时要服务写和读,都需要消耗CPU,为了能让数据库的吞吐变得更高,而业务又不在乎那几百微妙到毫秒级的延时差距,业务会把更多计算放到service层做,毕竟计算资源很好水平扩展,数据库很难啊,所以大多数业务会把纯计算操作放到service层做,而将数据库当成一种带事务能力的kv系统来使用,这是一种重业务,轻DB的架构思路

    第二:很多复杂的业务可能会由于发展的历史原因,一般不会只用一种数据库,一般会在多个数据库上加一层中间件,多个数据库之间还能做毛的join,自然业务会抽象出一个service层,降低对数据库的耦合。

    第三:对于一些大型公司由于数据规模庞大,不得不对数据库进行分库分表,这个问题我在《阿里为什么要禁用三表以上的join》上也回答过,对于分库分表的应用,使用join也受到了很多限制,除非业务能够很好的根据sharding key明确要join的两个表在同一个物理库中。而中间件一般对跨库join都支持不好。举一个很常见的业务例子,在分库分表中,要同步更新两个表,这两个表位于不同的物理库中,为了保证数据一致性,一种做法是通过分布式事务中间件将两个更新操作放到一个事务中,但这样的操作一般要加全局锁,性能很捉急,而有些业务能够容忍短暂的数据不一致,怎么做?让它们分别更新呗,但是会存在数据写失败的问题,那就起个定时任务,扫描下A表有没有失败的行,然后看看B表是不是也没写成功,然后对这两条关联记录做订正,这个时候同样没法用join去实现,只能将数据拉到service层应用自己来合并了。。。

    为什么互联网公司不让使用join?

    第一,不利于写操作。执行读操作时,会锁住被读的数据,阻塞其他业务对该部分数据的更新操作(U or D)。如果涉及多个聚合函数(缓存中没有max or min时),相当于同时锁住多张表,不能进行读写,直接影响其他业务,这影响了系统的整体性能;

    第二,不利于维护。业务发生变动时,比如join中一张表改了,可能导致系统中原有的sql不可用,最终导致基于该SQL执行结果的上层显示失败(也意味着以往的开发工作已无效)。如果使用步骤一和步骤二的方式,只需要修改其中一个步骤就行。实际工作中,也就是只需要修改其中的一个service(对应一张表)即可。

    既影响性能,又不利于维护,所以我们尽量不要用join。另外,集团不让用三张表,是在OLTP场景中。不要一叶障目哦,如果是在OLAP的应用场景中,使用join是非常合适的。

    我们平台过一段时间就会把生产数据库的慢查询导出来分析,要嘛修改写法,要嘛新增索引。以下是一些笔记、总结整理

     

    慢查询排查

            show status;  // 查询mysql数据库的一些运行状态

            show status like 'uptime'; // 查看mysql数据库启动多长时间,myisam存储引擎长时间启动需要进行碎片整理

            查看慢查询

            show status like 'slow_queries';

            查询慢查询时间

            show variables like 'long_query_time';

            设置慢查询时间 

            set long_query_time = 0.5;

    分析执行情况 EXPLAIN详解

            分析查询语句的执行情况,可以分析出所查询的表的一些特征

            EXPLAIN/DESCRIBE/DESCSELECT * FROM...;

    每个字段说明:

    idSELECT标识符。这是SELECT的查询序列号。

    select_type:表示SELECT语句的类型。它可以是以下几种取值:

        SIMPLE:表示简单杳询,其中不包括连接查询和子查询;

        PRIMARY:表示主查询,或者最外层的查询语句;

        UNION:表示连接查询的第2个或后面的查询语句;

        DEPENDENT UNION:连接查询中的第2个或后面的SELECT语句,取决于外面的查询;

        UNION RESULT:连接查询的结果;

        SUBQUERY:子查询中的第一个SELECT语句;

        DEPENDENT SUBQUERY:子查询中的第一个SELECT,取决于外面的查询;

        DERIVED:导出表的SELECT (FROM语句的子查询)。

    table:表示查询的表。

    type:表示表的连接类型。下面按照从最佳类型到最差类型的顺序给出各种连接类型:

        (1) system

            该表仅有一行的系统表。这是const连接类型的一个特例。

        (2) const

            数据表最多只有一个匹配行,它将在查询开始时被读取,并在余下的査询优化中作为常量对待。const表查询速度很快,因为它们只读取一次。const用于使用常数值比较PRIMARY KEY或UNIQUE索引的所有部分的场合。

            在下面查询中,tb1_name可用const表:

            SELECT  *  from tb1_name WHERE primary_key=1;

            SELECT * from tb1_name WHERE primary_key_part1=1 AND primary_key_part2=2

        (3) eq_ref

            对于每个来自前面的表的行组合,从该表中读取一行。当一个索引的所有部分都在查询中使用,并且索引是UNIQUE或者PRIMARY KEY时,即可使用这种类型。

            eq_ref可以用于使用“=”操作符比较带索引的列。比较值可以为常量或者一个在该表前面所读取的表的列的表达式。

            在下面例子中,MySQL可以使用eq_ref来处理ref_tables:

            SELECT * FROM ref_table,other_table WHERE ref_table.key_cloumn = other_table.cloumn;

            SELECT * FROM ref_table, other_tbale WHERE ref_table.key_cloumn_part1 = other_table.cloumn AND ref_table.key_cloumn_part2 = 1;

        (4)ref

            对于来自前面的表的任意组合,将从该表中读取所有匹配的行。这种类型用于索引既不是UNIQUE也不是PRIMARY KEY的情况,或者查询中使用了索引列在左子集,既索引中左边的部分列组合。ref可以用于使用=或者<=>操作符的带索引的列。

            以下的几个例子中,mysql将使用 ref 来处理ref_table:   

            select * from ref_table where key_column=expr; 

            select * from ref_table,other_table where ref_table.key_column=other_table.column; 

            select * from ref_table,other_table where ref_table.key_column_part1=other_table.column and ref_table.key_column_part2=1;

        (5)ref_or_null

            这种连接类型类似ref,不同的是mysql会在检索的时候额外的搜索包含null值的记录。在解决子查询中经常使用该链接类型的优化。

            在以下的例子中,mysql使用ref_or_null 类型来处理 ref_table:

            select * from ref_table where key_column=expr or key_column is null;

        (6)index_merge

            该链接类型表示使用了索引合并优化方法。在这种情况下,key列包含了使用的索引的清单,key_len包含了使用的索引的最长的关键元素。

        (7)unique_subquery

            该类型替换了下面形式的IN子查询的ref:

            value in (select primary_key from single_table where some_expr)

        (8)index_subquery

            这种连接类型类似 unique_subquery。可以替换IN子查询,不过它用于在子查询中没有唯一索引的情况下,

            例如以下形式:

            value in (select key_column from single_table where some_expr)

        (9)range

            只检索给定范围的行,使用一个索引来选择行。key列显示使用了哪个索引。ken_len包含所使用索引的最长关键元素。当使用 =, <>, >,>=, <, <=, is null, <=>, between, 或 in操作符,用常量比较关键字列时,类型为range。

            下面介绍几种检索制定行的情况:

            select * from tbl_name where key_column = 10; 

            select * from tbl_name where key_column between 10 and 20; 

            select * from tbl_name where key_column in (10,20,30); 

            select * from tbl_name where key_part1= 10 and key_part2 in (10,20,30);

        (10)index

             连接类型跟ALL一样,不同的是它只扫描索引树。它通常会比ALL快点,因为索引文件通常比数据文件小。

        (11)ALL

            对于前面的表的任意行组合,进行完整的表扫描。如果第一个表没有被标识为const的话就不大好了,在其他情况下通常是非常糟糕的。正常地,可以通过增加索引使得能从表中更快的取得记录以避免ALL。

    possible_keys

            possible_keys字段是指MySQL在搜索表记录时可能使用哪个索引。如果这个字段的值是NULL,就表示没有索引被用到。这种情况下,就可以检查WHERE子句中哪些字段哪些字段适合增加索引以提高查询的性能。创建一下索引,然后再用explain 检查一下。

    key

           key字段显示了MySQL实际上要用的索引。当没有任何索引被用到的时候,这个字段的值就是NULL。想要让MySQL强行使用或者忽略在 possible_keys字段中的索引列表,可以在查询语句中使用关键字force index, use index或 ignore index。参考SELECT语法。

    key_len

            key_len 字段显示了mysql使用索引的长度。当key 字段的值为NULL时,索引的长度就是NULL。注意,key_len的值可以告诉你在联合索引中MySQL会真正使用了哪些索引。

    ref

            表示使用哪个列或常数与索引一起来查询记录。

    rows

            显示MySQL在表中进行查询时必须检查的行数。 

    Extra

            本字段显示了查询中mysql的附加信息。以下是这个字段的几个不同值的解释

            distinct

            MySQL当找到当前记录的匹配联合结果的第一条记录之后,就不再搜索其他记录了。 

            not exists

            MySQL在查询时做一个LEFT JOIN优化时,当它在当前表中找到了和前一条记录符合LEFT JOIN条件后,就不再搜索更多的记录了。下面是一个这种类型的查询例子:

            select * from t1 left join t2 on t1.id=t2.id where t2.id is null;

            假使 t2.id 定义为 not null。这种情况下,MySQL将会扫描表 t1并且用 t1.id 的值在 t2 中查找记录。当在 t2中找到一条匹配的记录时,这就意味着 t2.id 肯定不会都是null,就不会再在 t2 中查找相同id值的其他记录了。也可以这么说,对于 t1 中的每个记录,mysql只需要在t2 中做一次查找,而不管在 t2 中实际有多少匹配的记录。

            range checked for each record (index map: #)

            mysql没找到合适的可用的索引。取代的办法是,对于前一个表的每一个行连接,它会做一个检验以决定该使用哪个索引(如果有的话),并且使用这个索引来从表里取得记录。这个过程不会很快,但总比没有任何索引时做表连接来得快。

            using filesort

            MySQL需要额外的做一遍从已排好的顺序取得记录。排序程序根据连接的类型遍历所有的记录,并且将所有符合where条件的记录的要排序的键和指向记录的指针存储起来。这些键已经排完序了,对应的记录也会按照排好的顺序取出来。详情请看"7.2.9how mysql optimizes order by"。

            using index

            字段的信息直接从索引树中的信息取得,而不再去扫描实际的记录。这种策略用于查询时的字段是一个独立索引的一部分。

            using temporary

            mysql需要创建临时表存储结果以完成查询。这种情况通常发生在查询时包含了group by和order by子句,它以不同的方式列出了各个字段。

            using where

            where子句将用来限制哪些记录匹配了下一个表或者发送给客户端。除非你特别地想要取得或者检查表种的所有记录,否则的话当查询的extra字段值不是using where并且表连接类型是all或index时可能表示有问题。

            如果你想要让查询尽可能的快,那么就应该注意extra字段的值为using filesort和using temporary的情况。    

    其他

    索引没起作用的情况

    1. 使用LIKE关键字的查询语句

            在使用LIKE关键字进行查询的查询语句中,如果匹配字符串的第一个字符为“%”,索引不会起作用。只有“%”不在第一个位置索引才会起作用。

    2. 使用多列索引的查询语句

            MySQL可以为多个字段创建索引。一个索引最多可以包括16个字段。对于多列索引,只有查询条件使用了这些字段中的第一个字段时,索引才会被使用。

    3. 使用OR关键字的查询语句

            查询语句的查询条件中只有OR关键字,且OR前后的两个条件中的列都是索引时,查询中才会使用索引。否则,查询将不使用索引。

    优化数据库结构

            合理的数据库结构不仅可以使数据库占用更小的磁盘空间,而且能够使查询速度更快。数据库结构的设计,需要考虑数据冗余、查询和更新的速度、字段的数据类型是否合理等多方面的内容。

    1. 将字段很多的表分解成多个表

            对于字段比较多的表,如果有些字段的使用频率很低,可以将这些字段分离出来形成新表。因为当一个表的数据量很大时,会由于使用频率低的字段的存在而变慢。

    2. 增加中间表

            对于需要经常联合查询的表,可以建立中间表以提高查询效率。通过建立中间表,把需要经常联合查询的数据插入到中间表中,然后将原来的联合查询改为对中间表的查询,以此来提高查询效率。

    3. 增加冗余字段

            设计数据库表时应尽量遵循范式理论的规约,尽可能减少冗余字段,让数据库设计看起来精致、优雅。但是合理加入冗余字段可以提高查询速度。 

    切分查询

            比如我们要删除旧的数据,可能需要一次性删除很多数据会锁住很多数据、占满整个事务日志、耗尽系统资源、阻塞很多小的但重要的查询。将一个大的DELETE语句切成多个较小的查询可以尽可能小的影响MySQL性能,同时还可以减少MySQL复制的延迟,如下:

            DELETE FROM table WHERE create_date < NOW(); 

            替换为

            rows_affected = 0

            do { 

                rows_affected = do_query(

                    "DELETE FROM table WHERE create_date < NOW() LIMIT 10000"    

                )

            } while rows_affected > 0

            一次删除一万行数据一般来说是一个比较高效而且对服务器影响也最小的做法,如果每次暂停一会会更好。

    分解关联查询

            有时候将一个大的查询分解为多个小查询是很有必要的。

            很多高性能的应用都会对关联查询进行分解,就是可以对每一个表进行一次单表查询,然后将查询结果在应用程序中进行关联,很多场景下这样会更高效,例如:

            SELECT * FROM tag 

            JOIN tag_post ON tag_id = tag.id

            JOIN post ON tag_post.post_id = post.id

            WHERE tag.tag = 'mysql';

            分解为:

            SELECT * FROM tag WHERE tag = 'mysql';

            SELECT * FROM tag_post WHERE tag_id = 1234;

            SELECT * FROM post WHERE post.id in (123,456,567);

            有很多场景都可以使用:比如当应用能够方便地缓存单个查询的结果的时候、当可以将数据分布到不同MySQL服务器上的时候、当能够使用IN()的方式代替关联查询的时候、当查询中使用同一个数据表的时候。

    优化LIMIT分页

            在分页偏移量很大的时候,如LIMIT 10000,20这样的查询,MySQL需要查询10020条记录然后只返回最后20条,前面10000条记录都被抛弃,这样代价非常高。

            优化的最简单的办法就是尽可能地使用索引覆盖扫描,而不是查询所有的列。然后根据需要做一次关联操作再返回所需的列,对于偏移量很大的时候,这样做的效率回提升很大,如下:

            SELECT file_id, description FROM film ORDER BY title LIMIT 50, 5;

            修改为:

            SELECT film.film_id, film.description FROM film 
            INNER JOIN (SELCT film_id FROM film ORDER BY title LIMIT 50, 5) AS lim USING(film_id);

            这里“延迟关联”将大大提升查询效率,它让MySQL扫描尽可能少的页面,获取需要访问的记录后在根据关联列回原表查询需要的所有列。

    展开全文
  • A,B两个表数据规模十几万,数据规模都不大,单机MySQL够用了,在单机的基础关联两表的数据,先说一个极端情况,A,B两个表都没有索引,并且关联是笛卡尔积,那关联结果会爆炸式增长,可能到亿级别,这个时候网络...

     

    A,B两个表数据规模十几万,数据规模都不大,单机MySQL够用了,在单机的基础上要关联两表的数据,先说一个极端情况,A,B两个表都没有索引,并且关联是笛卡尔积,那关联结果会爆炸式增长,可能到亿级别,这个时候网络IO成了瓶颈,这个时候两次十万行结果集的拉去可能远小于1次亿级别的结果集的拉取,那么将关联合并拉到service层做更快。但实际业务中一般不会有这么蠢的行为,一般关联会有连接条件,并且连接条件上会有索引,一般是有一个结果集比较小,拿到这个结果集去另一张表去关联出其它信息,如果放到service层去做,最快的方式是,先查A表,得到一个小的结果集,一次rpc,再根据结果集,拼凑出B表的查询条件,去B表查到一个结果集,再一次rpc,再把结果集拉回service层,再一次rpc,然后service层做合并,3次rpc,如果用数据库的join,关联结果拉回来,一次rpc,帮你省了两次rpc,当然数据库上做关联更快,对应到数据库就是一次blk nested loop join,这是业务常用情况。
    但是确实大多数业务都会考虑把这种合并操作放到service层,我觉得有几方面考虑:
    第一:单机数据库计算资源很贵,数据库同时要服务写和读,都需要消耗CPU,为了能让数据库的吞吐变得更高,而业务又不在乎那几百微妙到毫秒级的延时差距,业务会把更多计算放到service层做,毕竟计算资源很好水平扩展,数据库很难啊,所以大多数业务会把纯计算操作放到service层做,而将数据库当成一种带事务能力的kv系统来使用,这是一种重业务,轻DB的架构思路
    第二:很多复杂的业务可能会由于发展的历史原因,一般不会只用一种数据库,一般会在多个数据库上加一层中间件,多个数据库之间还能做毛的join,自然业务会抽象出一个service层,降低对数据库的耦合。
    第三:对于一些大型公司由于数据规模庞大,不得不对数据库进行分库分表,这个问题我在《阿里为什么要禁用三表以上的join》上也回答过,对于分库分表的应用,使用join也受到了很多限制,除非业务能够很好的根据sharding key明确要join的两个表在同一个物理库中。而中间件一般对跨库join都支持不好。举一个很常见的业务例子,在分库分表中,要同步更新两个表,这两个表位于不同的物理库中,为了保证数据一致性,一种做法是通过分布式事务中间件将两个更新操作放到一个事务中,但这样的操作一般要加全局锁,性能很捉急,而有些业务能够容忍短暂的数据不一致,怎么做?让它们分别更新呗,但是会存在数据写失败的问题,那就起个定时任务,扫描下A表有没有失败的行,然后看看B表是不是也没写成功,然后对这两条关联记录做订正,这个时候同样没法用join去实现,只能将数据拉到service层应用自己来合并了。。。
     
     
    作者:聿明leslie
    链接:https://www.zhihu.com/question/68258877/answer/264097272

    转载于:https://www.cnblogs.com/hnshi/p/8147338.html

    展开全文
  • 想到对数据本身进行分析:对关联字段进行groupby,然后进行关联,发现一般数据无法关联上,这样去除大部分数据。 最终解决方案,B进行自身groupby关联字段生成tmp1,然后tmp1关联B,之后再关联A (为...
  • Oracle数据索引问题

    2009-06-30 19:45:14
    今天项目发布这是我来到公司真正参与开发项目,但是实际因为其他工作要做投入在开发时间并不多。代码质量个人觉得也不怎么样...因为做了表关联的,但是张关联字段没有做索引,造成都是全表扫描这...
  • 在Form的数据源之间可以建立各种关系,连接的方式诸如InnerJoin,OuterJoin,Delay之类,可对于个数据源之间的通过哪些字段进行关联没有显示指定的地方,一直想当然地以为会按照从表上建立的关系连接,今天让这...
  • 在Form的数据源之间可以建立各种关系,连接的方式诸如InnerJoin,OuterJoin,Delay之类,可对于个数据源之间的通过哪些字段进行关联没有显示指定的地方,一直想当然地以为会按照从表上建立的关系连接,今天让这...
  • 说到索引,这就要提到我第一个真正处理百万行的审计项目,在这之前我有用sql处理10万行的数据,那个是要把表关联查询,你可以理解为用一个表vlookup另外一个表。足足反应了20分钟,我当时就放弃了用sql。跑...
  • sap日志记录

    2020-07-15 15:20:20
    日志记录 CDHDR更改凭证抬头 CDPOS 更改凭证项目 第一种方法 通过CDHDR关联CDPOS查询UNIT_OLD UNIT_NEW这个字段获取更改前后数据 ...首先需要将表的技术设置里面日志数据更改打勾 接着我们事务代...
  • int数据类型后面存储的是显示宽度,而不是存储宽度,其他的数据类型则表示的是存储宽度 now()sql中的内置函数,根据数据类型生成相对应的时间模式 char( )定长字符串,存储速度快,但是浪费空间 varchar( )变长...
  • excel使用

    2012-11-25 17:06:01
    输入完毕之后,再次按下键盘上的Ctrl键,然后使用鼠标左键单击所选择的多个工作,解除这些工作的联系,否则在一张表单中输入的数据会接着出现在选中的其它工作内。(6) 不连续单元格填充同一数据选中一个...
  • 105页的数据结构和算法 142页的Spring 58页的过滤器和监听器 30页的HTTP xxxx页的Redis:待更新...(最新首发公众号,导航更新可能有延迟) Hibernate AJAX ...... :coffee:Java基础 初学者学Java常遇到的问题,我...
  • 当客户机第一次调用一个Stateful Session Bean 时,容器必须立即在服务器中创建一个新Bean实例,并关联到客户机,以后此客户机调用Stateful Session Bean 方法时容器会把调用分派到与此客户机相关联的Bean实例...
  • 现代化办公要求软件能够一专多能,例如用同一种软件处理文字、表格、图片、数据库,甚至视频和声音,以减轻用户学习和经济上的负担。 WPS 2000 较好地考虑了中国人的这种需要,着力突出软件的易用性和实用性,使软件...
  • 人们往往看到杜蕾斯官方微博火爆光鲜外表,却没有注意到运营团队在背后进行大量数据分析。很多微博账号,内容发了就发了,至于它流向何方谁在参与就不再关心。优渡网不是这样。 每一条发布在杜蕾斯官方微博以及...
  • 人们往往看到杜蕾斯官方微博火爆光鲜外表,却没有注意到运营团队在背后进行大量数据分析。很多微博账号,内容发了就发了,至于它流向何方谁在参与就不再关心。优渡网不是这样。 每一条发布在杜蕾斯官方微博以及...
  • 用手机上的文件管理器,将他们剪切,粘贴到 /system/apps/软件名/ 目录下,覆盖就可以 了。  再打开,是不是就好了.  三安装例子  1 诺基亚手机 安装MP手机浏览器JAVA程序  安装 JAVA程序先要传输软件,安装...
  • LINGO软件学习

    2009-08-08 22:36:50
    为此,LINGO为用户提供了个可选部分:输入集成员和数据的数据部分(Data Section)和为决策变量设置初始值的初始部分(Init Section)。 3.1 模型的数据部分 3.1.1 数据部分入门 数据部分提供了模型相对静止部分...
  • 编译器现在托管堆分配一块内存空间(空间大小为对象中包含值类型变量所占空 间总和外加一个方法指针和一个SyncBlockIndex),然后把ageInt拷贝到这个空间中,再返回该空间引用地址。接下来第13行则是拆箱 ...
  • 没有应用于此对象公共标准。 应用到 [ 对象名称 ] 平台 版本 Win32: Unix: Win16: WinCE: Mac: 版本数据当鼠标指向链接或链接获得焦点时在此列出。 CUSTOM, window 将鼠标光标移动到应用到清单中...
  • 自从 Edgar F.Codd 第一次提出“数据可以被规范化为一组相互关联的表”这样思想以来,已经超过35年了。很少有哪一种软件技术敢声称自己像关系数据库和SQL那样经受住了时间考验。因此,关系数据库和SQL仍然很有...
  • 常见的数据结构分类方式如下图: <img alt="" src="http://my.csdn.net/uploads/201204/26/1335449398_7504.png" /><br /> 常用的线性结构有:线性表,栈,队列,循环队列ÿ...
  • 这种情况恶劣得多,你未保存和已经放在硬盘上的数据都可能会受到部分或全部的损失。  2、是黑客的潜在的木马发作,或是蠕虫类病毒发作,让你的机器不断地向外界发送你的隐私、或是利用你的名义和邮件地址发送垃圾...
  • eas供应链dep案例集

    2017-11-18 22:32:39
    现在情况是,单据类型为采购OR销售发票的其他应收应付单据,它的数据精度可以根据物料档案中设置的数据精度带出;(客户设置物料精度为四位小数,可看附图);但其他的单据类型选择费用项目后数据精度为六位;现在...
  • 6.8.4 创建PDF格式的数据表关联/引用关系图 100 6.8.5 格式转换(数据列内容的另类显示效果) 101 第7章 Microsoft Office和OpenOffice/StarOffice 103 7.1 安装Connector/ODBC 103 7.2 Microsoft Access 106 ...
  • 并确保在同一事务处理种对相同数据的两次查询看到是相同值。 值范围: TRUE | FALSE 默认值: FALSE row_locking: 说明: 指定在已更新或正在更新时是否获取行锁。如果设置为 ALWAYS, 只有在被更新后才获取...
  • 一个好用数据库类

    2008-05-14 08:36:06
    */ <br> /*下面的循环用于向列表框中插入数据, set.m_coldata是一个COL_DATA_ODBC的结构, 当含有当前行的数据值,数据值的长度信息,这样就实现了从记录集中取数据的功能。*/ int iRow = 0; while...
  • 什么是NoSQL数据库?

    2014-07-21 23:24:20
    由于数据被分散到了多个服务器上,减少了每个服务器上的数据量,即使要进行大量数据的写入操作,处理起来也更加容易。同理,数据的读入操作当然也同样容易。 提升性能和增大规模 下面说一点题外话,如果想要使...

空空如也

空空如也

1 2 3 4 5 6
收藏数 104
精华内容 41
关键字:

两表关联去没有关联上的数据