專案需求：使用者和組織機構服務平台。
1.單點登入
2.使用者和組織機構層級管理
初步不成熟設計（手動畫了一圖，字太醜，不好意思呈現，等週末有空補上）：
大致是這樣的：
1.整體分三部分：
1）外部單位（也就是單點登入白名單裡的單位）
2）組織機構分很多單位，有層級劃分，比如市，區縣，校等
3）各個單位下的使用者
2.三者之間關係：外部單位通過關聯組織機構單位中的id實現二者之間使用者的通用性。
3.技術關鍵點：
1）資料庫方面的設計。
因為該系統作為服務存在，使用者資料會被很多其他平台請求獲取，平台中的資料也會不斷的增加，因此使用者資料量會很龐大，怎麼設計資料庫成為該項目的重點之一。此處考慮了三點改進方案：
a.讀寫分離，配置主從資料庫，主資料庫負責增刪改，從資料庫承擔讀壓力。（此處，資料庫之間資料同步是重點，待研究）
b.使用者表的拆分。使用者錶可資料量會比較多，表查詢速度會相當慢了，因此考慮把使用者表拆分成幾個表。
拆分分為橫向拆分和垂直拆分。單條使用者資料的字段之間不便於拆分，而且資料量是個限制，橫向拆分並不能解決這個問題，因此此處暫不考慮橫向拆分（即把使用者的字段拆分成幾個表）。
垂直拆分是把使用者資料量分散開來，考慮三種垂直拆分方式：i）按照單位節點拆分。優點：符合業務邏輯，方便查詢，後期可擴充套件性大，拿到使用者能夠直接知道使用者在哪個表，不用建立使用者id和表的對應關係表，因此不會增加查詢資料次數；缺點：拆分的表不便於控制，表之間壓力分配不均。ii）按照id來拆分，比如1-1000放a表，10001-2000放b表，依次類推。優點：不會增加查詢次數，拆分簡單；缺點：擴充套件性差，壓力可能會分配不均。iii）按照餘數（不知道叫啥，假設叫餘數）方式拆分，將使用者id/10（也可以是2，3，5……）後的餘數來分表，比如餘1放到a表，餘2放到b表，依次類推，這樣分成十個表（分成十個表，分法簡單，也基本能滿足業務需求，如果資料量再大的話，就要考慮資料遷移了）。優點：能夠均勻分擔壓力；缺點：查詢不便。目前尚在i和ii之間猶豫選擇哪種方式。
c.快取（memcache），還沒考慮怎麼用。
2）完全跨域單點登入。
大致過程如上圖，實際就是產生ticket，驗證ticket的乙個過程，但ticket如何能作為不同應用和不同瀏覽器的憑證呢。（暫時有一點不成熟的想法，待驗證中）。應用a去認證系統時，認證系統檢測有沒有比如是ticket的cookie存在，如果沒有，則需要a登入，a通過認證系統登入時，認證系統在自己這裡寫乙個ticket，同時返回給應用使用者資訊，a應用再講使用者資訊處理後返回給瀏覽器，這樣a應用就是登入狀態了，並且在自己這裡寫入cookie，這樣a應用的其他頁面也都是登入狀態了。b應用去認證系統時，認證系統檢測名為ticket的cookie是否存在，如果存在說明是同一瀏覽器傳送的請求，並且已經處於登入狀態，認證系統驗證後直接返回給b使用者資訊，這樣b也是登入狀態了，同理c。這樣認證系統通過cookie能夠區分不同的客戶端了，再通過cookie裡的資訊來判斷a，b，c能否允許該使用者登入。
暫時選這樣，繼續不但完善中……
組織機構樹查詢
組織機構樹遞迴查詢 查詢父級節點的所有子節點 select organizational id,organizational name,parent id from sys organizational where is used 1 start with parent id 父級節點id conn...
組織機構 許可權 角色設計
迄今為止最為普及的許可權設計模型是rbac模型,基於角色的訪問控制 role based access control 1.1 rbac0模型 rbac0模型如下 這是許可權最基礎也是最核心的模型,它包括使用者 角色 許可權,其中使用者和角色是多對多的關係,角色和許可權也是多對多的關係。使用者是發起...
java 遞迴查詢組織機構樹
需求 不要在資料庫層寫儲存過程或者呼叫資料庫自帶方法實現，因為資料庫有可能是mysql或者是oracle。核心遞迴 description 遞迴查詢機構 param param departlist param param departid 設定檔案 return void 返回型別 throws ...