用户权限管理专题
方案一：多用户--多用户方法
前几天，有位网友问到关于用户权限的问题，我认为这个问题在PB的开发中都可能遇到，各人有各自的解决
方法，我以前也用过各种方法来实现，但是总体而言，安全性、方便性、灵活性等等方面考虑的话，下面的的
方案是一种比较好的方案。
以下就该方案做详细的说明：
一、基本知识：
现在主要的DBMS包括：ORACLE SQL Server,Sybase Adaptive Server 11,Microsoft SQL Server 6.x,7.x等，在这些DBMS中，都有自己完整的用户管理模式，一般都以下列方式进行：
登录用户：主要用来提供连接到数据库服务的；
角色用户：将登录用户划分为某些组，这些组拥有各种不同的数据库操作权限，而一个登录用户可以扮演不同的角色；
组管理 ：主要在Microsoft SQL Server 6.x中，在7.0中已经采用ORACLE,Sybase的用户管理方式；
DBMS提供了这些用户管理的基本方式，并各自对表、视图、过程、触发器等有各自的审计及管理的方法，关于这些内容，请参考相关书籍。
在实际的应用中，如果实际情况允许，可以对实际的所有用户建立一个登录用户（帐号），并对所有的帐号进行严密的权限管理。但是，如果用户的数量是不固定的，而且可能有上百个，那管理的复杂程度及难度就可想而知了。
所以，在一般的应用系统中，很少直接采用DBMS提供的用户管理模式而进行相关的扩充。
二、实现方法
当前比较可行的方法的要点是：
1、所有的实体（表、视图等等）都由一个登录用户建立（dbo）、但是该用户不拥有连接及操作这些 实体的权限（Insert,Delete,Update等等）；
2、对所有的实际用户进行分类，归纳为几个具体的角色（实际角色）；
3、一种实际角色对应一个登录用户，建立帐号系统，进行角色分配、权限设置；
4、在Application中，某用户连接时，根据所扮演的实际角色，以对应的登录用户登录；
5、根据对应表中对该用户的可用模块（功能），进行适当处理，使用户只在定制的]、允许的范围内进行 功能操作及数据库操作。
根据以上几点，在一个具体的应用中，涉及到的开发工作包括：
表设计：
1、实际角色（组）分析；
2、建立应用用户帐户表，该表记录了该用户所属的组，建立用户组表；
3、建立一个通用连接用户（只能检索用户帐户表），所有的应用用户初始都以该用户连接数据库，然后检索根据实际登录的用户及用户所属组，以该组对应的登录用户进行连接；
4、建立模块（功能）表，建立用户、用户组与该表的对应表，即某用户到底能够进行什么样的操作；
功能设计：
5、建立模块（功能）管理器，管理所有可用模块的相关信息；
6、建立用户，用户组权限管理器，管理某用户（组）能够使用的功能；
用户启动应用录时，将按照以下过程进行：
○ 所有用户都以固定的连接用户进行初始连接
→ 用户输入自己的代码及口令，根据帐户表确认该用户
→ 得到该用户所属的组（即可以连接到数据库的登录用户名称）等信息
→ 重新连接到数据库，分配角色
→ 根据角色，进行数据分片（参考数据分片技术）
→ 检索该用户所属组及该用户可用的模块信息及布置，调整菜单或界面
● 打开主窗口，结束。
--------------------------------------------------------------------------------
方案二：单用户-多用户模式
所谓单用户-多用户模式，指数据库的登录用户模式，指所有应用都以统一的用户登录， 该用户拥有所有表、视图、过程、函数等的所有操作权限，而这些对象都被dbo所创建和拥有，可以将这些用户称为应用用户（存放在某表中）；而登录到数据库的这个用户即为模式用户； 实际上，为了防止系统外数据登录，可增加一个联接用户，该用户只能读取一张表，该表记录了模式用户的登录参数（具体部分可以加密存放）； 这种单-多用户方式在大型的mis系统中，由于其实现简单，思路清晰，所以应用是相当多的， 单其优缺点是明显的：
优点：
设置简单，特别是授权，可以比较轻松地实现；
管理简单，只要维护一个模式用户就可以了；
对开发人员是透明的，即开发用户以dbo方式登录就可以了；
缺点：
比较危险，一旦该模式用户泄密，将造成巨大损失；
无法进行进一步的权限设置，因为不知道到底某应用用户到底具有那些权限；
改进：（多用户－多用户方式）
可以按照实际业务系统的分类，划分为几个模式用户，如库房，给库房一个模式用户， 财务，则给财务另外一个模式户，这些模式用户对不同的对象拥有不同的权限，从而防止了破坏 不相关的业务系统数据的可能。
在实际的使用中，在登录时，可以根据该用户所在的部门进行相关的联接设置。
方案三：通过菜单来控制用户权限
在PowerBuilder中，是不支持动态菜单的，一个菜单只能先做好，然后在程序中调用或修改它的属性，因此，对于动态菜单的实现，只能通过打开一个个窗口实例来实现，可以通过修改某菜单项的tag属性，在该菜单项的clicked事件中打开该tag所指示的窗口即可。
动态菜单的实现可以分为以下步骤：
一、准备工作：
1、建立模块属性表，包括所有需要分配的模块的窗口名称、标题、图标、Microhelp,ToolbarItemText等属性；
2、建立部门可用菜单表，包括部门号、menu_bar、顺序，可用窗口名称等属性；
3、建立部门模块管理功能，此功能主要分配某部门可以打开那些模块，以及这些模块如何布置。
二、动态菜单实现：
1、创建一个菜单，m_main_frame,含所有部门都需要的项，如[文件]、[窗口]、[帮助]等，然后在中间加入
10个menu_bar,每个menu_bar下建立20个menu_item（可以按实际情况增减）；
2、在每个menu_item下调用函数mf_open_module(this.tag)，该函数即用于打开窗口（模块）;
3、程序运行时，在main_frame的open事件中，根据当前用户所在的部门，修改该用户的菜单属性，包括：
itemText,microhelp,toolbarItemName,toolbaritemtext,visible,enabled等等；
4、通过以上步骤，显示给用户的界面就是由系统管理员所定制的菜单。
三、优缺点：
1、优点：
快速的开发框架，可以立即进行实际业务系统的开发而不用理会相关开发框架技术上的问题。
可以充分扩展模块，只需要加入某补丁库中即可，其他程序不用修改；
可以由系统管理员充分自由地定制每个部门或用户的可用模块；
模块容量无实际限制，可多可少；
可以扩展给用户自己定义菜单的显示方式，如文字、microhelp，图标等。
对开发人员，可以提供增加模块到模块表中的辅助工具，其他开发框架问题可以不用考虑；
2、缺点：
需要建立额外的两张表（模块表、部门模块定义表），增加工作量；
目前只能以opensheet()方式打开main形式的窗口（可以扩展打开response,pop类型的窗口）
目前只实现了二级菜单，更多级别的菜单尚未实现，但原理是一致的。
函数mf_open_module参考：
//
// Function: mf_open_module
// Access: Public
// Arguments: string as_module_id
// Returns: None
// Description: 打开模块(sheet)
// Designer: 刘建刚
// Date: 2000/1/10
//
Integer li_sheet, li_Resp
Window lw_Ex,lw_sheet
if isnull(as_module_id) or as_module_id = ‘‘ then
messagebox(‘参数错误‘,‘请检查模块ID设置。‘)
else
lw_sheet = parentwindow.GetFirstSheet()
do while isvalid(lw_sheet)
if lw_sheet.classname() = as_module_id then
Opensheet(lw_sheet,parentwindow,0,original!)
return
end if
lw_sheet = parentwindow.GetNextSheet(lw_sheet)
loop
li_Resp = Opensheet(lw_Ex, as_module_id,parentwindow,0,original!)
end if
--------------------------------------------------------------------------------
方案之四：分离为多个子系统
分离为多个子系统方式，即根据业务规则，将模块按业务所在部门进行分类，
通常一个业务部门为一个子系统，各子系统有独立的application,main_menu,main_window，
相互之间没有任何关系，有独立的可执行程序，独立的设置。
优缺点：
1、优点：
独立性，各业务系统相互关联少;
自由性，可以定制特定的内容，如界面等；
不需要辅助控制；
2、缺点：
各分系统需要考虑各自的框架，增加额外工作量；
系统修改、扩展性差、需要重新编译整个分系统；
代码可重用部分少，容易造成整理不一致。
前几天，有位网友问到关于用户权限的问题，我认为这个问题在PB的开发中都可能遇到，各人有各自的解决
方法，我以前也用过各种方法来实现，但是总体而言，安全性、方便性、灵活性等等方面考虑的话，下面的的
方案是一种比较好的方案。
以下就该方案做详细的说明：
一、基本知识：
现在主要的DBMS包括：ORACLE SQL Server,Sybase Adaptive Server 11,Microsoft SQL Server 6.x,7.x等，在这些DBMS中，都有自己完整的用户管理模式，一般都以下列方式进行：
登录用户：主要用来提供连接到数据库服务的；
角色用户：将登录用户划分为某些组，这些组拥有各种不同的数据库操作权限，而一个登录用户可以扮演不同的角色；
组管理 ：主要在Microsoft SQL Server 6.x中，在7.0中已经采用ORACLE,Sybase的用户管理方式；
DBMS提供了这些用户管理的基本方式，并各自对表、视图、过程、触发器等有各自的审计及管理的方法，关于这些内容，请参考相关书籍。
在实际的应用中，如果实际情况允许，可以对实际的所有用户建立一个登录用户（帐号），并对所有的帐号进行严密的权限管理。但是，如果用户的数量是不固定的，而且可能有上百个，那管理的复杂程度及难度就可想而知了。
所以，在一般的应用系统中，很少直接采用DBMS提供的用户管理模式而进行相关的扩充。
二、实现方法
当前比较可行的方法的要点是：
1、所有的实体（表、视图等等）都由一个登录用户建立（dbo）、但是该用户不拥有连接及操作这些 实体的权限（Insert,Delete,Update等等）；
2、对所有的实际用户进行分类，归纳为几个具体的角色（实际角色）；
3、一种实际角色对应一个登录用户，建立帐号系统，进行角色分配、权限设置；
4、在Application中，某用户连接时，根据所扮演的实际角色，以对应的登录用户登录；
5、根据对应表中对该用户的可用模块（功能），进行适当处理，使用户只在定制的]、允许的范围内进行 功能操作及数据库操作。
根据以上几点，在一个具体的应用中，涉及到的开发工作包括：
表设计：
1、实际角色（组）分析；
2、建立应用用户帐户表，该表记录了该用户所属的组，建立用户组表；
3、建立一个通用连接用户（只能检索用户帐户表），所有的应用用户初始都以该用户连接数据库，然后检索根据实际登录的用户及用户所属组，以该组对应的登录用户进行连接；
4、建立模块（功能）表，建立用户、用户组与该表的对应表，即某用户到底能够进行什么样的操作；
功能设计：
5、建立模块（功能）管理器，管理所有可用模块的相关信息；
6、建立用户，用户组权限管理器，管理某用户（组）能够使用的功能；
用户启动应用录时，将按照以下过程进行：
○ 所有用户都以固定的连接用户进行初始连接
→ 用户输入自己的代码及口令，根据帐户表确认该用户
→ 得到该用户所属的组（即可以连接到数据库的登录用户名称）等信息
→ 重新连接到数据库，分配角色
→ 根据角色，进行数据分片（参考数据分片技术）
→ 检索该用户所属组及该用户可用的模块信息及布置，调整菜单或界面
● 打开主窗口，结束。
--------------------------------------------------------------------------------
方案二：单用户-多用户模式
所谓单用户-多用户模式，指数据库的登录用户模式，指所有应用都以统一的用户登录， 该用户拥有所有表、视图、过程、函数等的所有操作权限，而这些对象都被dbo所创建和拥有，可以将这些用户称为应用用户（存放在某表中）；而登录到数据库的这个用户即为模式用户； 实际上，为了防止系统外数据登录，可增加一个联接用户，该用户只能读取一张表，该表记录了模式用户的登录参数（具体部分可以加密存放）； 这种单-多用户方式在大型的mis系统中，由于其实现简单，思路清晰，所以应用是相当多的， 单其优缺点是明显的：
优点：
设置简单，特别是授权，可以比较轻松地实现；
管理简单，只要维护一个模式用户就可以了；
对开发人员是透明的，即开发用户以dbo方式登录就可以了；
缺点：
比较危险，一旦该模式用户泄密，将造成巨大损失；
无法进行进一步的权限设置，因为不知道到底某应用用户到底具有那些权限；
改进：（多用户－多用户方式）
可以按照实际业务系统的分类，划分为几个模式用户，如库房，给库房一个模式用户， 财务，则给财务另外一个模式户，这些模式用户对不同的对象拥有不同的权限，从而防止了破坏 不相关的业务系统数据的可能。
在实际的使用中，在登录时，可以根据该用户所在的部门进行相关的联接设置。
方案三：通过菜单来控制用户权限
在PowerBuilder中，是不支持动态菜单的，一个菜单只能先做好，然后在程序中调用或修改它的属性，因此，对于动态菜单的实现，只能通过打开一个个窗口实例来实现，可以通过修改某菜单项的tag属性，在该菜单项的clicked事件中打开该tag所指示的窗口即可。
动态菜单的实现可以分为以下步骤：
一、准备工作：
1、建立模块属性表，包括所有需要分配的模块的窗口名称、标题、图标、Microhelp,ToolbarItemText等属性；
2、建立部门可用菜单表，包括部门号、menu_bar、顺序，可用窗口名称等属性；
3、建立部门模块管理功能，此功能主要分配某部门可以打开那些模块，以及这些模块如何布置。
二、动态菜单实现：
1、创建一个菜单，m_main_frame,含所有部门都需要的项，如[文件]、[窗口]、[帮助]等，然后在中间加入
10个menu_bar,每个menu_bar下建立20个menu_item（可以按实际情况增减）；
2、在每个menu_item下调用函数mf_open_module(this.tag)，该函数即用于打开窗口（模块）;
3、程序运行时，在main_frame的open事件中，根据当前用户所在的部门，修改该用户的菜单属性，包括：
itemText,microhelp,toolbarItemName,toolbaritemtext,visible,enabled等等；
4、通过以上步骤，显示给用户的界面就是由系统管理员所定制的菜单。
三、优缺点：
1、优点：
快速的开发框架，可以立即进行实际业务系统的开发而不用理会相关开发框架技术上的问题。
可以充分扩展模块，只需要加入某补丁库中即可，其他程序不用修改；
可以由系统管理员充分自由地定制每个部门或用户的可用模块；
模块容量无实际限制，可多可少；
可以扩展给用户自己定义菜单的显示方式，如文字、microhelp，图标等。
对开发人员，可以提供增加模块到模块表中的辅助工具，其他开发框架问题可以不用考虑；
2、缺点：
需要建立额外的两张表（模块表、部门模块定义表），增加工作量；
目前只能以opensheet()方式打开main形式的窗口（可以扩展打开response,pop类型的窗口）
目前只实现了二级菜单，更多级别的菜单尚未实现，但原理是一致的。
函数mf_open_module参考：
//
// Function: mf_open_module
// Access: Public
// Arguments: string as_module_id
// Returns: None
// Description: 打开模块(sheet)
// Designer: 刘建刚
// Date: 2000/1/10
//
Integer li_sheet, li_Resp
Window lw_Ex,lw_sheet
if isnull(as_module_id) or as_module_id = ‘‘ then
messagebox(‘参数错误‘,‘请检查模块ID设置。‘)
else
lw_sheet = parentwindow.GetFirstSheet()
do while isvalid(lw_sheet)
if lw_sheet.classname() = as_module_id then
Opensheet(lw_sheet,parentwindow,0,original!)
return
end if
lw_sheet = parentwindow.GetNextSheet(lw_sheet)
loop
li_Resp = Opensheet(lw_Ex, as_module_id,parentwindow,0,original!)
end if
--------------------------------------------------------------------------------
方案之四：分离为多个子系统
分离为多个子系统方式，即根据业务规则，将模块按业务所在部门进行分类，
通常一个业务部门为一个子系统，各子系统有独立的application,main_menu,main_window，
相互之间没有任何关系，有独立的可执行程序，独立的设置。
优缺点：
1、优点：
独立性，各业务系统相互关联少;
自由性，可以定制特定的内容，如界面等；
不需要辅助控制；
2、缺点：
各分系统需要考虑各自的框架，增加额外工作量；
系统修改、扩展性差、需要重新编译整个分系统；
代码可重用部分少，容易造成整理不一致。