我觉得主键还是使用Varchar，这样移植性比较好，不依赖数据库。另外呢，对于使用Hibernate的GUID生成（包括自增INT类型数据生成），不是很适合我们目前的应用，例如用户在界面上新增加了两个站点和一条连接这两个站点的光纤，我们需要保存三个对象，光纤需要知道两个站点的主键以便构造自己的实例，如果依赖Hibernate生成则需要先存储两个站点之后才能得到站点的主键，如果我们自己生成GUID则不会这么麻烦。另外自己生成INT类型的GUID，在多线程、并发的环境中算法是很复杂很复杂的，而Varchar则有现成的算法（聪哥哥在一年多前已经无耻的验证过没有问题了）所以我建议使用Varchar类型。

对于用户权限，目前我看到的只有模块权限，当前的需求可能都不能完全满足，遑论我们要把这个模型提升到我们的公共模型。举两个例子，第一个例子是，某个县级公司的老大，其用户属性归属于A县，但是其管理职能却覆盖A县和B县，在这个情况下，我们就没法弄了，因为默认的我们是按照用户属性进行地区权限的控制；第二个例子是，某个系统管理员新增加了一些站点，这些站点只为GPRS服务，这个用户能看到的站点是“其归属地所在的所有的GPRS站点”，但是只对“其归属地所在的自己创建的GPRS站点”有编辑权限，这下我们的权限系统就无能为力了。

所以，我需要聪哥哥设计表格的时候，将“资源授权”放到表格中，资源授权包含默认的资源授权（不需要写入数据库表格的，例如用户管理中只能对所辖地区的用户进行管理）也包含显式的资源授权（明确指定某个角色或者某个用户对某个资源有什么样的权限，嗯，这不就是表结构？）

权限应该存在时间限制，默认是无限的，但是也存在临时授权的情况，典型的例子就是省公司某君到地市检查一个月的工作，这个时候这厮应该有该地市的管理员权限，但是只有一个月，为了防止地市管理员忘记收回权限，这个时间限制就是必须的了。

用户组是不是就是角色的概念？如果不是，可能就没什么意思了，呵呵。如果是，还是修改表格名称为角色吧。

用户授权还涉及到另外的三个小问题：

第一个是跨角色授权，在绝大多数的情况下，用户使用的是角色授权，但是有的时候有些管理员不愿意建立一个角色，而是直接指定某个用户对某个资源的权限，这种情况也应该支持，这就需要扩展授权的那张表格，字段大致为:
    授权实体类型：枚举值，值为用户或者角色
    授权实体代码
    资源类型
    资源代码或者令牌
    授权时效模型：枚举值，限时和不限时
    授权时效时间（2个字段，开始和结束）
    权限令牌：读、写、可读可写等等，应该不局限于枚举值

第二个就是常见的菜单授权被Hack的情况如何避免的问题。常用的菜单授权都是授权到相对的URL，正常情况下根据权限显示菜单，用户看不到菜单自然也就无法访问页面，但是这不能排除用户直接输入URL进行Hack操作的情况，主要原因是页面自己本身没有校验机制，页面无法知道当前的用户是否能够访问这个自己。我以前的做法是独立一个令牌出来，页面知道用户只有持有特定令牌的用户才能访问本页面，管理员授权的时候针对令牌授权而不是URL，这样即时URL怎么变化，页面也知道自己应该被什么样的人访问。授权关系为
    用户-->----角色---own>-----令牌---<hold-----页面
    这个方案大家讨论一下。
对于用户表格还遗漏了一些东西，我们的客户主要是移动和联通的，塞班斯法案说起来虽然是个P，但是怕的就是客户嚼汁，用户可能希望实现如下功能：
    1、使用电话号码和用户属性绑定，电话号码等同于登陆代码，两者都可以。
    2、遗忘密码的时候可以主动索取临时密码，临时密码通过短信发送给用户，临时密码存在时效，一般从创建起半小时之后自动失效。
    3、某些用户因为各种原因，不设定固定密码，每次都需要使用短信取得密码使用临时密码登陆。
    4、用户不能修改自己的手机号码（这点你们能够理解为什么吗？），用户不能修改自己所处的地区代码等等。
    5、用户绑定一张门禁卡，使用门禁卡刷卡可以登陆（这个我在学校项目中遇到过）
这个需要在用户上面增加几个字段，例如登陆策略，密码策略，密码时效等等。也需要在安装配置中增加系统级别的限制，毕竟有些系统对这些比较放松而有些系统严格。

第三个问题就是IP限制的问题，登陆需要有一个IP策略支持，例如某些用户（Admin）只能从服务器本机登陆而不能通过外网登陆，某些IP坚决不允许登陆，而某些IP段用户允许登陆等等，这个理解起来相当简单，俺就不浪费口水了。
一个系统管理就被俺弄出这么多的问题，聪哥哥，任重而道远啊。