論許可權設計

都是老生常談的東西，我只是做乙個總結。

我接觸過的許可權設計一般都是做成功能型別的，不會顆粒度很細。許可權關係有很多種設計與實現，有顆粒度細的，對資料做許可權管理的（比

較喜歡，一般這樣的系統都是需要定製的，很難做到通用化。），顆粒度大的，也就是常用的，大都是根據功能上的劃分模組來做。

如果是顆粒度比較粗的

比如，我列出我們需要的建的表。

管理使用者表：存各種管理員基礎資訊

角色表：儲存各種角色資訊，這也是許可權細化的第一部分，多角色系統。

功能表：儲存功能模組的資訊，列出功能的的結構

然後就是他們的關聯了，然後為了功能的重用，加入功能的分組，以乙個功能組的形式分配給角色，然後應用於管理員使用者。

這就是顆粒度大，但是比較通用的許可權設計。

如果是顆粒度比較細的

同上建立表結構，但是在功能表的設計的時候，要細化，對每個功能模組設計詳細的功能描述，比如常用的增刪查改，資料的匯入匯出，盡

量。這個時候要加乙個功能描述的字段，可以以分隔符進行分隔，然後再功能使用時載入這個描述，生成對應的介面。

如果是資料上的顆粒度細化呢（上述兩種，我都有過實踐，這個只是與人討論過，沒有付諸實踐）

理論上講，對資料進行細顆粒化的設計就要對錶資料進行一定的控制，經常做的就是加乙個標示欄位已作區分。講資料的許可權分配到角色的

級別。也就是在你想要做資料細顆粒化的表上加乙個角色標示（我不怎麼建議直接加使用者的標示，範圍太小）。這樣，對於不同的角色就有

了不同的資料。如果在細分下去，就要對角色再進行細化。暫時思考到這裡。

論許可權設計

都是老生常談的東西，我只是做乙個總結。我接觸過的許可權設計一般都是做成功能型別的，不會顆粒度很細。許可權關係有很多種設計與實現，有顆粒度細的，對資料做許可權管理的 比 較喜歡，一般這樣的系統都是需要定製的，很難做到通用化。顆粒度大的，也就是常用的，大都是根據功能上的劃分模組來做。如果是顆粒度比較粗的...

SAP高階 再論SAP許可權

直觀的說，許可權就是 某人能幹某事 和 某人不能幹某事 之合。在sap系統中，用事務碼 也稱交易 或者tcode 或者transaction code 表示乙個使用者能幹的事情。比如mm01這個tcode是用來維護物料資料的 migo是用來收貨的 fs00是用來維護會計科目的等。用su01 新建乙個...

許可權設計（功能許可權與資料許可權）

許可權設計的最終目標就是定義每個使用者可以在系統中做哪些事情。當我們談到許可權的時候，一般可以分為 功能許可權 資料許可權和字段許可權 功能許可權 使用者具有哪些權利，比如特定單據的增 刪 改 查 審批 反審批等等 一般按照乙個人在組織內的工作內容來劃分 比如乙個單據往往有錄入人和審批人，錄入人具有...