写后台总结

多对多关系的表，如果删除某个表的行，另外一个表怎么处理，关系表怎么处理

1. 比如模板表和模块表，还有一个中间关系表。
2. 因为模板引用模块，他们之间的引用关系在中间关系表里有数据表征，如果删除一个模板，中间表不用删除，因为查找模板所对应模块的时候，首先要到模板表里查找是否有该模板，而且中间表没有status字段表达是否被删除，它只是一个表达一个关系而已。
3. 因为模块被模板引用，当删除模块时，要先判断是否有被引用（在中间表里查找即可），如果有被引用，则不能删除。
4. 关系表永远只有被动处理

为什么后台对数据结构和算法要求很高，我现在是了解了

1. 当用sql语句从数据库里拿到数据，需要解析成前端所需要的各种格式的数据，这时候各种数组，对象的操作，遍历等，怎么算节省效率，这时候就需要很强的数据操作能力了。

关于数据库设计

1. 使用逻辑外键，而非物理外键
2. 设计表，刚开始不用想太多，想到怎样就设计成怎样好了，后面具体到细节的时候再修改。
3. 数据库范式

• 1NF： 字段是最小的的单元不可再分
• 2NF：满足1NF,表中的字段必须完全依赖于全部主键而非部分主键
• 3NF：满足2NF,非主键外的所有字段必须互不依赖
• 4NF：满足3NF,消除表中的多值依赖

1. 查询的时候不要使用select * ，一是影响查询速度，二是如果数据库字段改了，前台的变量名也要跟着改了
2. 视图，从表中到出的一个子集，可以限制每个用户可看到的数据库的区域
3. 数据库设计过程

• 先设计实体关系图(ERD)
• 设计表结构

1. 应避免过多表的连接查询，连接查询中表越多，查询的执行速度越慢
2. 对于有父子关系的表，修改某一条数据，也要修改其下一级的数据，从而形成一个递归修改。

方法1: mysql 只能用函数来实现递归

delimiter // 
CREATE FUNCTION `getParList`(rootId INT)
RETURNS varchar(1000) 
BEGIN
    DECLARE sTemp VARCHAR(1000);
    DECLARE sTempPar VARCHAR(1000); 
    SET sTemp = ''; 
    SET sTempPar =rootId; 
 
    #循环递归
    WHILE sTempPar is not null DO 
        #判断是否是第一个，不加的话第一个会为空
        IF sTemp != '' THEN
            SET sTemp = concat(sTemp,',',sTempPar);
        ELSE
            SET sTemp = sTempPar;
        END IF;
        SET sTemp = concat(sTemp,',',sTempPar); 
        SELECT group_concat(pid) INTO sTempPar FROM treenodes where pid<>id and FIND_IN_SET(id,sTempPar)>0; 
    END WHILE; 
 
RETURN sTemp; 
END

方法2: 在表中多加一个字段存所有父级的id，每次insert的时候将父级id拼起来存到表里, 后面查找的时候用 like 语句匹配，显然这种方法效率更高

1. 规范化不是关系型数据库设计最重要的目标。对于第一二三范式，不需要严格遵守。有时候规范化粒度过细所导致的问题不比其所解决的问题少。
2. 现在关系型数据库模型不会扩充到3nf上，有时连3nf也不用，原因在于生成的表太多，所得的sql代码连接很复杂导致数据库响应时间过长，而且磁盘空间并不贵。4nf，5nf，dknf等趋向于在表中加入一些业务逻辑，这一点并无必要。应该由程序来处理业务逻辑，数据库只存数据。
3. 软删除和唯一约束的冲突

软删除把state改为1之后，记录还存在。如果某一个字段是唯一约束的话，比如name，那么新增一个被删除掉一样name的记录，就会报唯一键约束的错误。

Mysql

1. Mysql 比较灵活，既可以嵌入到应用程序中，也可以支持数据仓库，内容索引和部署软件，高可用的冗余系统，在线事务处理（OLTP）
2. 写锁（write lock）会减少并发，但是又是不可避免的。所以要让锁定对象更有选择性，尽量只锁定需要修改的部分数据。锁定的数据越少，系统的并发程度越高。锁策略就是控制锁的粒度。
3. Mysql提供表锁（table lock），行锁（row lock）
4. 死锁，指两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源，并导致恶性循环

start transaction;
update stock_price set close = 10 where id=1
update stock_price set close = 12 where id=2
commit;

start transaction;
update stock_price set high = 100 where id=2
update stock_price set high = 120 where id=1
commit;

如果两个事务都执行了第一条update语句，同时锁定了该行数据，接着每个事务都尝试去执行第二条update语句，却发现该行已经被对方锁定，然后两个事务都等待对方释放锁，同时又持有对方需要的锁，则陷入死循环。
目前InnoDB处理死锁的方式是，将持有最少行级排他锁的事务进行回滚。

数据库优化

1. 避免多表查询返回所有列，如下，查询的列越多，时间越长

select * from t_agent
left join t_admin on t_agent.agent_id=t_admin.agent_id_fk
left join t_agent_ex on t_agent_agent_id=t_admin.agent_id_fk

1. 避免查询重复的数据，比如经常需要查询的数据可以放到缓存里
2. 对于查询需要扫描大量数据（比如列表查询），使用索引覆盖扫描，把用于where查询条件的列放到索引里。常用的查询条件列比如 agent_name 可以放到索引里。因为单查 agent_name 的情况比较多。

select * from t_agent where agent_name='sam'

1. 是否将一个复杂查询转换成多个简单查询。在传统的实现中，强调在数据库层尽可能完成多的工作，这样做的逻辑是以前认为网络通信的代价很高，但是现在的网络越来越快，这方面的代价很小。当然，分开查询也是有代价的，这个问题需要在实际问题中衡量。
2. 删除大量数据时，可以一次删除一部分，比如一万行数据，分多次删除。
3. 复杂的多表查询，可以分开查，然后在后台代码里组装数据（当然用多表查询，可以简化代码）。

4GL语言

• 1GL 二进制语言
• 2GL 汇编语言 二进制语言的文本缩写
• 3GL 高级编程语言 c js java等
• 4GL sql 两个特征 非过程性的；面向表的

业务参数和鉴权参数应该分开，如果鉴权参数在某些接口里也作为业务参数，那么就多传一次参数作为业务参数，鉴权参数还是统一处理。

一般来说，鉴权参数统一放在header里，或者放在url里。

后台比前台更能积累经验，因为后台更容易抽象。

后台的业务逻辑会抽象成数据模型，属于高度抽象，越高的抽象越容易复用，做一次业务，就相当于积累了一次数据模型，下次碰到相同的业务直接复用就行了；相比较前端ui，本来就难抽象，目前最多也就抽象到组件这一层，而且同一套业务可以套不同的ui，等于说你做了这个业务的ui，换了老板说不行，还是要重写一套。