[笔记系列文章说明]: 该类型的文章是笔者学习过程中整理的学习笔记.

NOSQL

认识MongoDB

流行的数据库Oracle,SqlServer,MySql为关系性数据库,相对的,也有非关系性数据库,统称为NoSql,而MongoDB就是NoSql的其中一种.

关系性数据库特点

• 高度组织化结构化数据
• 结构化查询语言（SQL） (SQL)
• 数据和关系都存储在单独的表中。
• 数据操纵语言，数据定义语言
• 严格的一致性
• 基础事务

非关系型数据库特点

• 代表着不仅仅是SQL
• 没有声明性查询语言
• 没有预定义的模式
• 键 - 值对存储，列存储，文档存储，图形数据库
• 最终一致性，而非ACID属性
• 非结构化和不可预知的数据
• CAP定理
• 高性能，高可用性和可伸缩性

  由上可以看出,关系型数据库更加安全,严谨,而非关系型数据库更加追求性能.从他们遵从的原则同样可以得出以上结论

[笔记系列文章说明]: 该类型的文章是笔者学习过程中整理的学习笔记.

分类

常用二叉树有:
完全二叉树,平衡二叉树,红黑树,满二叉树等

二叉树有4种遍历方式

1. 前序遍历:

   首先访问根，再先序遍历左（右）子树，最后先序遍历右（左）子树

2. 中序遍历:

   首先中序遍历左（右）子树，再访问根，最后中序遍历右（左）子树

3. 后序遍历:

   首先后序遍历左（右）子树，再后序遍历右（左）子树，最后访问根

4. 层次遍历:

   即按照层次访问，访问根，访问子女，再访问子女的子女（越往后的层次越低）（两个子女的级别相同,通常先左后右）

   阅读全文 »

[笔记系列文章说明]: 该类型的文章是笔者学习过程中整理的学习笔记.

起因

在项目中有用到某表作为数据来源，在页面以列表的形式显示。使用的数据库是Oracle，分页的时候使用到了rownum这个关键字。
列表有排序功能，自然也用到了order by。
接下来问题出现了，我在用order by查询数据库数据的时候显示的内容，和页面列表处显示的内容竟然不一致。心里想不明白，各种倒腾，终于弄明白了其中一二。

首先说结论

当使用order by与rownum结合时,请一定保证order by后有一个能保证唯一的列
例如 select t.* from person t order by t.age,t.id; //id为主键,age可能重复

接下来验证之前的现象和我得出的结论

1,首先创建表

1

create table A_LXZ (id int ,name VARchar2(10),age int)

2,插入数据

1
2
3
4
5
6
7
8
9
10
11

insert into A_LXZ(id,name,age)values(1,'a',3);
insert into A_LXZ(id,name,age)values(2,'b',4);
insert into A_LXZ(id,name,age)values(3,'c',5);
insert into A_LXZ(id,name,age)values(4,'d',6);
insert into A_LXZ(id,name,age)values(8,'h',7);
insert into A_LXZ(id,name,age)values(9,'i',7);
insert into A_LXZ(id,name,age)values(6,'f',7);
insert into A_LXZ(id,name,age)values(5,'e',7);
insert into A_LXZ(id,name,age)values(7,'g',7);
insert into A_LXZ(id,name,age)values(10,'j',8);
insert into A_LXZ(id,name,age)values(11,'k',9);

[Design pattern]: 设计模式相关系列

介绍

概念： 表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
应用场景： 实体之间内部属性有差别，而且实体类型经常增加。他们的调用方式相同，但是调用的规则经常变化。
缺点： 实体的特殊内容访问类需要知道。

CODE

实体基类

1
2
3
4
5

package note.com.visitor;
public abstract class Food {

    public abstract void show(IVisitor visitor);
}

[Design pattern]: 设计模式相关系列

介绍

概念： 给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
应用场景： 语言解释器（把我们能看懂的代码转换成了难看懂的机器码）
好处： 以简单的方式使用复杂的东西。

CODE

解释器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

package note.com.interpreter;

/**
 * 解释器
 * @author lxz
 *
 */
public class Interpreter {

    public void say(String lag){
        if("nh".equals(lag)){
            System.out.println("你好");
        }
    }
}

[Design pattern]: 设计模式相关系列

介绍

概念： 用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
应用场景： 不同功能的模块之间调用关系复杂，耦合度高，不利于修改时使用。
好处： 降低耦合，模块独立。
坏处： 中介者业务复杂，不易维护。

CODE

定义模块抽象类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

package note.com.mediator;

public abstract class Element {
    public Mediator mediator = null;

    public abstract void good();

    public abstract void bad();

    public Mediator getMediator() {
        return mediator;
    }

    public void setMediator(Mediator mediator) {
        this.mediator = mediator;
    }

    public abstract void changeGood();

    public abstract void changeBad();
}

[Design pattern]: 设计模式相关系列

介绍

概念: 定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。
应用场景: 用户主动切换执行规则，比如 画图工具，不同的工具执行的事件效果不同. 压缩工具的格式，不同的格式执行不同的压缩算法.
好处: 扩展容易，不会破坏原有的结构，遵循开闭原则。
与状态模式的区别： 与状态模式的区别在于切换应对策略的主动权在用户，而状态模式的切换是在内部。

CODE

工具基类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

package note.com.strategy;

/**
 * 工具基类
 * @author lxz
 *
 */
public abstract class ATool {

    public abstract void leftMouseClick();

    public abstract void rightMouseClick();

    public abstract void leftDoubleMouseClick();

}

[Design pattern]: 设计模式相关系列

介绍

首先明白两个单词:打开和关闭是同一个物体的两种状态,是需要经常互相切换的,不是没有关系的两个单词. let`s Go

概念: 允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。
应用场景: 关闭着的门–》打开的门–》关闭的门，自动的切换到下一个状态的可执行事件。
好处: 控制对象内部不同的状态执行不同的操作，按照状态流程执行。

典型的状态模式例子

CODE

状态接口

1
2
3
4
5
6
7
8
9
10
11
12
13

package note.com.state;

/**
 * 状态接口定义
 * @author lxz
 *
 */
public interface State {
     State changeState();
     void doOne();
     void doTwo();
     void doThree();
}

[Design pattern]: 设计模式相关系列

介绍

概念: 将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。
应用场景: 统一处理器的入口,由一个公共的入口来执行各种各样的请求
好处: 扩展方便,入口统一

CODE

处理器的接口定义

1
2
3
4
5
6
7

package note.com.Command;

public interface ICommand {

    public void doICommand(String label);

}

[Design pattern]: 设计模式相关系列

介绍

概念: 使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
应用场景: 经常增加处理场景的业务,比如处理零食商品的类,不断有新增的零食,就需要不断增加处理零食的方法,耦合度太高.为了降低耦合度使用职责链模式.
好处: 扩展灵活.结构清晰.

CODE