返回Json的層級結構

上回說到

需求：機構資訊 - 左側新增組織架構，按系統-父機構-子機構-部門-使用者顯示

從需求可以看出返回的json物件必須是具有層級結構的，解決這個需求首先要思考的是返回json的層級結構及包含關係

提出猜想

因為是層級的包含關係

1、所有父機構所在的系統子機構必在其中

2、同理，子機構包含的部門，父機構必然包含

因為，向上我們只需要找出頂級父輩的所在系統

向下我們只需找出底級子輩所在的部門

這樣思路就清晰了，我們只需要遞迴找出機構表，所有機構的層級結構即可

對應的返回層級：

系統部門

...}}}

驗證猜想

使用sql遞迴查詢資料(這個地方只是驗證過程，後面並不需要使用遞迴sql，無需擔心)

id       instid  instcode    instname    parentid                         

1        1111     0001        白虎隊        0

131    2222    0002        灰狼隊        1111

132    3333    0003        青龍隊        2222

164    4444    0004        赤蛇隊        3333

查詢機構角色表，找到機構對應的角色id

instid    role_id

1111    root

2222    null

3333     null

4444    null

在這裡就可以看出我們的第乙個猜想是正確的，因為只有頂級父節點才有角色id，

也就證明了其他子節點是無法通過角色id查詢到對應的系統資訊，即系統資訊只有頂級父節點才有

查詢角色表，找到對應的系統name

select sys_name from role where role_id = "root";

查詢系統表，找到對應的系統資訊

select * from t_ims_auth_sys where sys_name = "炒雞**隊";

經過驗證發現猜想1在資料庫中的對映關係正是這樣,而猜想2卻在資料庫中的對映關係和我們猜想的並不同，

這也證明了當有解決問題的想法出現時，一定要查詢資料庫驗證，保證理論正確，才可以得出正確的操作步驟

那讓我們來看一下猜想2**出錯了

select * from t_ims_auth_user where inst_name ="白虎隊";

經過查詢資料庫我們發現，使用機構名稱查詢使用者表時，即使是頂級父輩也有對應的使用者資訊

(實際上經查詢是每級都有使用者資訊和部門資訊的)，即使用者資訊並不僅僅保留在底級子輩機構中

層級結構

ok，但這並不妨礙我們解決問題

上述證明我們設想的層級結構其實是有一點問題的，進行修改後，我們的層級結構終於出現了

(累の不行，真事   注:真事=真的是這樣)

系統部門資訊

...子機構}}

細節處理

部門和員工之間的關係可以通過map進行關係處理

先根據機構名稱，查詢所有的對應的user

select * from t_ims_auth_user where inst_name ="白虎隊";

遍歷使用者，寫入map，key為部門名稱  value為user資訊

listlist = ...

mapmap = ...
for(user user:list)
map.put(user.getdeptname,user)
}

這樣我們整個業務流程就算是捋清了

樹形結構json資料返回

適用於父子關係的資料結構。從資料庫中查詢所有位址 select select t.id as addressid,t.address name as addressname,t.parent id as parentid from t equipment address t public listg...

將層級結構的文字轉換為json資料

結構a 結構b1 結構c1 結構d1 結構e1 結構f1 結構f2 結構f3 結構f4 結構c2 結構d2 結構d3 結構d4 結構c2 結構b2將類似這種以 為層級標誌的文字轉換為json格式資料 以自底向上的方式，先對最後一行的子節點向上進行遍歷，遍歷過程中依次尋找其父親，直到最後的父節點遍歷完...

目錄的層級結構

在linux2.6以後的核心版本當中，乙個核心任務可以被搶占，從而提高系統的實時性。可以極大地增強 系統的使用者互動性。就如使用者覺得滑鼠單擊的時候得到了更快速的相應。但是2.6以後的核心還是存在一些 不可搶占的區間，例如中斷上下文，軟中斷上下文和自旋鎖鎖住的區間。如果給linux打上rt pree...