欧美一级黄色录像片,日韩欧美在线播放视频,男人操女人逼免费视频

導(dǎo)讀數(shù)據(jù)庫(kù)，簡(jiǎn)而言之可視為電子化的文件柜——存儲(chǔ)電子文件的處所，用戶可以對(duì)文件中的數(shù)據(jù)進(jìn)行新增、截取、更新、刪除等操作。所謂“數(shù)據(jù)庫(kù)”是以一定方式儲(chǔ)存在一起、能與多個(gè)用戶共享、具有盡可能小的冗余度、與應(yīng)...

數(shù)據(jù)庫(kù)，簡(jiǎn)而言之可視為電子化的文件柜——存儲(chǔ)電子文件的處所，用戶可以對(duì)文件中的數(shù)據(jù)進(jìn)行新增、截取、更新、刪除等操作。所謂“數(shù)據(jù)庫(kù)”是以一定方式儲(chǔ)存在一起、能與多個(gè)用戶共享、具有盡可能小的冗余度、與應(yīng)用程序彼此獨(dú)立的數(shù)據(jù)集合。

但凡涉及多用戶不同權(quán)限的網(wǎng)絡(luò)或者單機(jī)程序，都會(huì)有權(quán)限管理的問題，比較突出的是MIS系統(tǒng)。
下面我要說的是MIS系統(tǒng)權(quán)限管理的數(shù)據(jù)庫(kù)設(shè)計(jì)及實(shí)現(xiàn)，當(dāng)然，這些思路也可以推廣開來應(yīng)用，比如說在BBS中用來管理不同級(jí)別的用戶權(quán)限。
權(quán)限設(shè)計(jì)通常包括數(shù)據(jù)庫(kù)設(shè)計(jì)、應(yīng)用程序接口(API)設(shè)計(jì)、程序?qū)崿F(xiàn)三個(gè)部分。
這三個(gè)部分相互依存，密不可分，要實(shí)現(xiàn)完善的權(quán)限管理體系，必須考慮到每一個(gè)環(huán)節(jié)可行性與復(fù)雜程度甚至執(zhí)行效率。
我們將權(quán)限分類，首先是針對(duì)數(shù)據(jù)存取的權(quán)限，通常有錄入、瀏覽、修改、刪除四種，其次是功能，它可以包括例如統(tǒng)計(jì)等所有非直接數(shù)據(jù)存取操作，另外，我們還可能對(duì)一些關(guān)鍵數(shù)據(jù)表某些字段的存取進(jìn)行限制。除此，我想不出還有另外種類的權(quán)限類別。
完善的權(quán)限設(shè)計(jì)應(yīng)該具有充分的可擴(kuò)展性，也就是說，系統(tǒng)增加了新的其它功能不應(yīng)該對(duì)整個(gè)權(quán)限管理體系帶來較大的變化，要達(dá)到這個(gè)目的，首先是數(shù)據(jù)庫(kù)設(shè)計(jì)合理，其次是應(yīng)用程序接口規(guī)范。
我們先討論數(shù)據(jù)庫(kù)設(shè)計(jì)。通常我們使用關(guān)系數(shù)據(jù)庫(kù)，這里不討論基于Lotus產(chǎn)品的權(quán)限管理。
權(quán)限表及相關(guān)內(nèi)容大體可以用六個(gè)表來描述，如下：
1 角色（即用戶組）表：包括三個(gè)字段，ID，角色名，對(duì)該角色的描述；
2 用戶表：包括三個(gè)或以上字段，ID，用戶名，對(duì)該用戶的描述，其它（如地址、電話等信息）；
3 角色-用戶對(duì)應(yīng)表：該表記錄用戶與角色之間的對(duì)應(yīng)關(guān)系，一個(gè)用戶可以隸屬于多個(gè)角色，一個(gè)角色組也可擁有多個(gè)用戶。包括三個(gè)字段，ID，角色I(xiàn)D，用戶ID；
4 限制內(nèi)容列表：該表記錄所有需要加以權(quán)限區(qū)分限制的數(shù)據(jù)表、功能和字段等內(nèi)容及其描述，包括三個(gè)字段，ID，名稱，描述；
5 權(quán)限列表：該表記錄所有要加以控制的權(quán)限，如錄入、修改、刪除、執(zhí)行等，也包括三個(gè)字段，ID，名稱，描述；
6 權(quán)限-角色-用戶對(duì)應(yīng)表：一般情況下，我們對(duì)角色/用戶所擁有的權(quán)限做如下規(guī)定，角色擁有明令允許的權(quán)限，其它一律禁止，用戶繼承所屬角色的全部權(quán)限，在此范圍內(nèi)的權(quán)限除明令禁止外全部允許，范圍外權(quán)限除明令允許外全部禁止。該表的設(shè)計(jì)是權(quán)限管理的重點(diǎn)，設(shè)計(jì)的思路也很多，可以說各有千秋，不能生搬硬套說某種方法好。對(duì)此，我的看法是就個(gè)人情況，找自己覺得合適能解決問題的用。
先說第一種也是最容易理解的方法，設(shè)計(jì)五個(gè)字段：ID，限制內(nèi)容ID，權(quán)限ID，角色/用戶類型（布爾型字段，用來描述一條記錄記錄的是角色權(quán)限還是用戶權(quán)限），角色/用戶ID，權(quán)限類型（布爾型字段，用來描述一條記錄表示允許還是禁止）
好了，有這六個(gè)表，根據(jù)表六，我們就可以知道某個(gè)角色/用戶到底擁有/禁止某種權(quán)限。
或者說，這么設(shè)計(jì)已經(jīng)足夠了，我們完全實(shí)現(xiàn)了所需要的功能：可以對(duì)角色和用戶分別進(jìn)行權(quán)限定制，也具有相當(dāng)?shù)目蓴U(kuò)展性，比如說增加了新功能，我們只需要添加一條或者幾條記錄就可以，同時(shí)應(yīng)用程序接口也無須改動(dòng)，具有相當(dāng)?shù)目尚行浴５牵诔绦驅(qū)崿F(xiàn)的過程中，我們發(fā)現(xiàn)，使用這種方法并不是十分科學(xué)，例如瀏覽某個(gè)用戶所擁有的權(quán)限時(shí)，需要對(duì)數(shù)據(jù)庫(kù)進(jìn)行多次（甚至是遞歸）查詢，極不方便。于是我們需要想其它的辦法。使用過Unix系統(tǒng)的人們都知道，Unix文件系統(tǒng)將對(duì)文件的操作權(quán)限分為三種：讀、寫和執(zhí)行，分別用1、2、4三個(gè)代碼標(biāo)識(shí)，對(duì)用戶同時(shí)具有讀寫權(quán)限的文件被記錄為3，即1+2。我們也可以用類似的辦法來解決這個(gè)問題。初步的想法是修改權(quán)限列表，加入一個(gè)字段：標(biāo)識(shí)碼，例如，我們可以將錄入權(quán)限標(biāo)識(shí)為1，瀏覽權(quán)限標(biāo)識(shí)為2，修改權(quán)限標(biāo)識(shí)為4，刪除權(quán)限標(biāo)識(shí)為8，執(zhí)行權(quán)限標(biāo)識(shí)為16，這樣，我們通過權(quán)限累加的辦法就可以輕易的將原本要分為幾條記錄描述的權(quán)限放在一起了，例如，假定某用戶ID為1，庫(kù)存表對(duì)應(yīng)的限制內(nèi)容ID為2，同時(shí)規(guī)定角色類型為0、用戶類型為1，我們就可以將該用戶具有錄入、瀏覽、修改、刪除庫(kù)存表的權(quán)限描述為：2,15,1,1。
確實(shí)很簡(jiǎn)單，不是嗎？甚至還有更過激的辦法，將限制內(nèi)容列表也加上一列，定義好標(biāo)識(shí)碼，這樣，我們甚至可以用簡(jiǎn)單的一條記錄描述某個(gè)用戶具有的對(duì)全部?jī)?nèi)容所具有的全部權(quán)限了。當(dāng)然，這樣做的前提是限制內(nèi)容數(shù)量比較小，不然，呵呵，2的n次方遞增起來可是數(shù)量驚人，不容易解析的。
從表面上看，上述方法足以達(dá)到實(shí)現(xiàn)功能、簡(jiǎn)化數(shù)據(jù)庫(kù)設(shè)計(jì)及實(shí)現(xiàn)的復(fù)雜度這個(gè)目的，但這樣做有個(gè)弊端，我們所涉及的權(quán)限列表不是相互獨(dú)立而是互相依賴的，比如說修改權(quán)限，其實(shí)是包含瀏覽權(quán)限的，例如，我們可能只是簡(jiǎn)單的設(shè)置用戶對(duì)庫(kù)存表存取的權(quán)限值為錄入+修改+刪除（1+4+8=13),但事實(shí)上，該用戶具有(1+2+4+8=15）的權(quán)限，也就是說，在這種方案中，13=15。于是當(dāng)我們調(diào)用API詢問某用戶是否具有瀏覽權(quán)限時(shí)，就必須判斷該用戶是否具有對(duì)該數(shù)據(jù)表的修改權(quán)限，因此，如果不能在程序中固化權(quán)限之間的包含關(guān)系，就不能利用應(yīng)用程序接口簡(jiǎn)單的做出判斷。但這與我們的目的“充分的可擴(kuò)展性”矛盾。
這個(gè)問題如何解決？我想到了另外一種設(shè)置標(biāo)識(shí)碼的方法，那就是利用素?cái)?shù)。我們不妨將錄入、瀏覽、修改、刪除、執(zhí)行的基本標(biāo)志碼定為2,3,5,7,11，當(dāng)遇到權(quán)限互相包含的時(shí)候，我們將它的標(biāo)識(shí)碼設(shè)定為兩個(gè)（或多個(gè)）基本標(biāo)志碼的乘積，例如，可以將“修改”功能的標(biāo)志碼定為3*5=15，然后將所有的權(quán)限相乘，就得到了我們需要的最終權(quán)限標(biāo)識(shí)值。這樣，我們?cè)谠儐栍脩羰欠窬哂心稠?xiàng)權(quán)限的時(shí)候，只需要將最終的值分解成質(zhì)因子，例如，我們可以定義一個(gè)用戶具有錄入+修改+刪除庫(kù)存表的權(quán)限為 2*15*7=2*3*5*7，即表示，該用戶具有了對(duì)庫(kù)存表錄入+瀏覽+修改+刪除權(quán)限。
當(dāng)然，對(duì)權(quán)限列表我們使用上述方法的前提是權(quán)限列表記錄條數(shù)不會(huì)太多并且關(guān)系不是十分復(fù)雜，否則，光是解析權(quán)限代碼就要機(jī)器忽悠半宿：）
我希望以上的分析是正確且有效的（事實(shí)上，我也用這些的方法在不止一套系統(tǒng)中實(shí)現(xiàn)），但無論如何，我覺得如此實(shí)現(xiàn)權(quán)限管理，只是考慮了數(shù)據(jù)庫(kù)設(shè)計(jì)和應(yīng)用程序接口兩部分內(nèi)容，對(duì)于實(shí)現(xiàn)，還是顯得很費(fèi)勁。因此，我懇請(qǐng)有過類似設(shè)計(jì)、實(shí)現(xiàn)經(jīng)驗(yàn)的同志們提出建設(shè)性的意見和修改建議。
另外，關(guān)于數(shù)據(jù)庫(kù)設(shè)計(jì)的思路還有使用二維表的，這將在以后的時(shí)間里討論，關(guān)于應(yīng)用程序接口的設(shè)計(jì)和實(shí)現(xiàn)我也將在利用另外篇幅和大家共同探討，代碼將用類C語法實(shí)現(xiàn)（我不喜歡pascal，抱歉）
歡迎朋友們和我聯(lián)系，mailto:berg@91search.com，也歡迎訪問我和另外一位朋友共同建設(shè)的網(wǎng)站：http://www.91search.com，那里將有一個(gè)音樂搜索的工具軟件提供下載。

========================================
關(guān)于權(quán)限包容關(guān)系通過角色和權(quán)限掩碼來實(shí)現(xiàn)。
/// <summary>
/// 權(quán)限保護(hù)類型枚舉類型。
/// </summary>
public enum ProtectEnum
{
  /// <summary>撤回權(quán)限保護(hù)類型</summary>
  RevokeProtect = 0,
  /// <summary>授予權(quán)限保護(hù)類型</summary>
  GrantProtect = 1,
  /// <summary>拒絕權(quán)限保護(hù)類型</summary>
  DenyProtect  = 2
}
[page_break]/// <summary>
/// 系統(tǒng)固定用戶或角色枚舉類型。
/// </summary>
/// <remarks>
/// 管理員角色：16399 = 100000000001111
/// 所有者角色：16385 = 100000000000001
/// 只讀者角色：16386 = 100000000000010
/// 安全員角色：16388 = 100000000000100
/// 配置員角色：16392 = 100000000001000
/// </remarks>
public enum FixedRoleEnum
{
  ///<summary>系統(tǒng)管理員固定用戶</summary>
  Administrator = 1,
  ///<summary>系統(tǒng)管理員固定角色</summary>
  Administrators = 16399,
  ///<summary>所有者固定角色（具有讀寫操作之權(quán)限）</summary>
  Authors  = 16385,
  ///<summary>只讀者固定角色（具有只讀操作之權(quán)限）</summary>
  Readers  = 16386,
  ///<summary>系統(tǒng)安全管理員固定角色</summary>
  Security = 16388,
  ///<summary>系統(tǒng)設(shè)置管理員固定角色</summary>
  Setting  = 16392
}
/// <summary>
/// 系統(tǒng)權(quán)限枚舉類型。
/// </summary>
public enum PermissionEnum
{
  /// <summary>“讀取”權(quán)限</summary>
  FetchPermission = 1,
  /// <summary>“新增”權(quán)限</summary>
  AddNewPermission = 2,
  /// <summary>“更新”權(quán)限</summary>
  UpdatePermission = 4,
  /// <summary>“刪除”權(quán)限</summary>
  DeletePermission = 8,
  /// <summary>“打印”權(quán)限</summary>
  PrintPermission = 16,
  /// <summary>系統(tǒng)保留，應(yīng)用于流程處理</summary>
  FlowPermission = 1024,
  /// <summary>系統(tǒng)保留，應(yīng)用于流程處理</summary>
  VoidPermission = 2048
}
如果用戶“Popeye”對(duì)“銷售出倉(cāng)單[2009]”系統(tǒng)對(duì)象具有讀寫（讀取＋修改＋刪除＋新增）權(quán)限：（權(quán)限表定義如下TPermission）
FormID       UID           Permission
=======      ====          ==========
2009         Popeye        1+2+4+8=15
***** 上面系統(tǒng)定義的默認(rèn)權(quán)限肯定是不夠系統(tǒng)使用的，那么還有一些權(quán)限（例如：報(bào)關(guān)系統(tǒng)中的“計(jì)算差異表”“制造申報(bào)單”等權(quán)限，就由系統(tǒng)再定義），其實(shí)不用太擔(dān)心會(huì)不夠用的，因?yàn)樵谝粋€(gè)Form中不可能會(huì)出現(xiàn)所有權(quán)限情況，所以，系統(tǒng)自定義的權(quán)限掩碼可重復(fù)使用在不同的表單中。*****
　　建議不要把角色和用戶分開兩張表來存儲(chǔ)（可參考MS-SQL Server中的sys_users表），因?yàn)樵诤竺娴臋?quán)限定義表需要引用這個(gè)表的UID（其可為用戶或角色，SQL中是使用UID的數(shù)值范圍來區(qū)別用戶與角色的，建議也如此。），版主說的角色與用戶分開對(duì)待權(quán)限設(shè)置，這點(diǎn)我不贊成。因?yàn)榻巧徊贿^是一種用戶組，其應(yīng)該享用用戶的權(quán)限定義范圍，在其下屬的角色成員（注意角色成員不同于用戶或角色哦，其可以為角色也可以為用戶）均默認(rèn)繼承其定義的權(quán)限，除非角色成員重新指派其上級(jí)角色定義的權(quán)限字。下面給出我的相關(guān)表定義：
TUser(用戶或角色表)
===================
(PK)UID   int              NOT NULL（主鍵）
Name      nvarchar(50)     NOT NULL（唯一性約束）
FullName  nvarchar(100)    NULL
Description   nvarchar(255)  NULL
MasterNo  varchar(25)     NULL（注：該字段對(duì)應(yīng)為員工表中的員工編號(hào)，通過該字段就可以關(guān)聯(lián)知道該用戶或角色所屬的員工了，在企業(yè)管理系統(tǒng)中很有用啊！）
TMember(用戶與角色關(guān)系表)
=========================
(*PK)RoleID    int   NOT NULL
(*PK)UserID    int   NOT NULL
TPermission(用戶權(quán)限表)
=======================
(*PK)FormID    int   NOT NULL（表示系統(tǒng)中各個(gè)模塊或表單的唯一編號(hào)）
(*PK)UserID    int   NOT NULL（用戶或角色編號(hào)）
Protect        bit   NOT NULL（1：表示顯示授予權(quán)限；0：表示顯示拒絕權(quán)限）
Permission     int   NOT NULL（權(quán)限掩碼和）
***** 如果哪位兄弟有意研究權(quán)限與流程定制方面的東東，相信找偶是沒錯(cuò)的了！！！呵呵～～～    老板，給分啊～～～～～×××××

==========================================
以上的方法與我做的項(xiàng)目的方法基本一致，現(xiàn)摘一部分的表結(jié)構(gòu)，以供大家參考
create table t_workelement /*工作元素表*/
(
code varchar(20) not null, /*元素的代碼，唯一*/
name varchar(50)  not null UNIQUE,/*元素的名稱，唯一*/
type int  not null, /*類型 0-單據(jù)操作 1-報(bào)表操作 2-功能操作*/
bcode varchar(20) null,  /*對(duì)應(yīng)操作的單據(jù)\報(bào)表\功能的代碼*/
style int  null,  /*單據(jù)：類型 0-查看 1-新增 2-修改 3-刪除*/
      /*報(bào)表：無*/
      /*功能：無*/
term ntext  null,  /*單據(jù)：查看\修改\刪除時(shí)要符合的條件,如"{$承攬合同.編號(hào)}=12\n{$承攬合同.名稱}<>’afd’"*/
primary key(code)
)
go
drop table t_role
go
create table t_role /*角色表*/
(
name varchar(30) not null,
category varchar(50) null,
remark varchar(100) null,
primary key(name)
)
go
drop table t_roleelement
go
create table t_roleelement /*角色元素操作表*/
(
rname varchar(30) not null, /*角色名稱*/
ecode varchar(20) not null, /*元素的代碼*/
primary key(rname,ecode)
)
go
drop table t_users
go
create table t_users /*用戶表*/
(
name varchar(20) not null, /*用戶的名稱*/
dcode varchar(20) not null, /*所屬的部門*/
category varchar(50) null,  /*用戶的類別*/
pswd varchar(15) null,  /*密碼*/
primary key(name)
)
go
/*插入系統(tǒng)管理員*/
INSERT INTO t_users
(
name,
dcode,
category,
pswd
)
VALUES
(
’Admini’,
’system’,
’超級(jí)用戶’,
’’
)
go
drop table t_userrole
go
create table t_userrole /*用戶角色表*/
(
uname varchar(20) not null, /*用戶名稱*/
rname varchar(30) not null, /*角色的名稱*/
primary key(uname,rname)
)
go
INSERT INTO t_userrole
(
uname,
rname
)
VALUES
(
’Admini’,
’系統(tǒng)管理員’
)
go
drop table t_dept
go
create table t_dept /*部門表*/
(
code varchar(20) not null, /*部門的代碼*/
name varchar(50) not null UNIQUE,/*部門的名稱*/
type varchar(10) null,  /*部門的類別行政倉(cāng)庫(kù) 車間*/
subtype varchar(16) null,  /*子類別成品倉(cāng)庫(kù) 原料倉(cāng)庫(kù)自定義*/
primary key(code)
)
go
/*插入系統(tǒng)管理部*/
INSERT INTO t_dept
(
code,
name,
type
)
VALUES
(
’system’,
’系統(tǒng)管理部’,
’行政’
)
go

全新的路由器不僅讓你更穩(wěn)定快速地連接無線網(wǎng)絡(luò)，更可以讓家中的智能設(shè)備連接在一起。

溫馨提示：喜歡本站的話，請(qǐng)收藏一下本站！

當(dāng)前位置:雨林木風(fēng)下載站 > 應(yīng)用軟件教程 > 詳細(xì)頁面

權(quán)限設(shè)計(jì)的探討

本類教程下載

系統(tǒng)下載排行