写后台总结

时间 2019-11-10

标签后台总结繁體版

原文原文链接

多对多关系的表，若是删除某个表的行，另一个表怎么处理，关系表怎么处理

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

为何后台对数据结构和算法要求很高，我如今是了解了

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

关于数据库设计

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

1NF：字段是最小的的单元不可再分

2NF：知足1NF,表中的字段必须彻底依赖于所有主键而非部分主键

3NF：知足2NF,非主键外的全部字段必须互不依赖

4NF：知足3NF,消除表中的多值依赖

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

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

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

方法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 语句匹配，显然这种方法效率更高java

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

软删除把state改成1以后，记录还存在。若是某一个字段是惟一约束的话，好比name，那么新增一个被删除掉同样name的记录，就会报惟一键约束的错误。node

Mysql

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

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处理死锁的方式是，将持有最少行级排他锁的事务进行回滚。mysql

数据库优化

避免多表查询返回全部列，以下，查询的列越多，时间越长

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

避免查询重复的数据，好比常常须要查询的数据能够放到缓存里
对于查询须要扫描大量数据（好比列表查询），使用索引覆盖扫描，把用于where查询条件的列放到索引里。经常使用的查询条件列好比 agent_name 能够放到索引里。由于单查 agent_name 的状况比较多。

select * from t_agent where agent_name='sam'

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

4GL语言

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

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

通常来讲，鉴权参数统一放在header里，或者放在url里。算法

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

后台的业务逻辑会抽象成数据模型，属于高度抽象，越高的抽象越容易复用，作一次业务，就至关于积累了一次数据模型，下次碰到相同的业务直接复用就好了；相比较前端ui，原本就难抽象，目前最多也就抽象到组件这一层，并且同一套业务能够套不一样的ui，等于说你作了这个业务的ui，换了老板说不行，仍是要重写一套。sql