寫後臺總結

多對多關係的表，若是刪除某個表的行，另一個表怎麼處理，關係表怎麼處理

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，換了老闆說不行，仍是要重寫一套。