没看海洋和另一个兄弟的设计。
我的想法是对资源应该有统一的ID，先甭管它是什么，真身是什么，存在哪个表里。
有的时候这样的设计不可得，这时可以考虑从权限角度讲，如何能有一种可用的、可扩展的资源定位的方式。
其次是对无差别资源条目的共同操作，可以被抽象和实现到一处。
可以参考的例子有很多（也说了很多遍），比如NTFS上文件管理的Access Control。
类似设计里面存在的一个疑问是，不同的资源操作可能不同，其实这只是一个约定和解释的问题。
这一点不比文件管理复杂，只有一些可以商榷的细节。比如，对于不同资源的不同操作，我们如何编码。
根据目标特征，特殊的编码方式一定会有其自身的好处，不过将会要求我们实现更复杂的动态翻译。
这种复杂将体现在CRUD以及更高层次操作的各个方面，所以还需谨慎。
和这种设计相关的一种具体实现是位运算这种方式，很多系统采用这种方式是有道理的，为什么呢？
我倒是不太赞成说位运算的实现能快多少，即便差别有几十倍几百倍，但至少不是指数级的差距。
（非说效率的话，关键是不同的问题交织在一起时，权限验证所花费的时间是如何被放大的，这个很看具体场景。）
主要是，它通过重新利用废掉的bit，纯粹降低了复杂度(trick本身是好理解的)；而且没有真正产生Trade Off。
我们可以考虑，一个xx位的数据，其中大多数bit可能是对当前要验证的（用户、数据、操作）元组没有用的。
这本来是一种冗余，将会带来空间和运行时间的浪费，但这被计算机本身的特点避免了：没有冗余也需要相同代价。
冗余发挥的作用显而易见，一个运算代替了所有的其它设计可能存在的复杂实现，这里就不多说了。
一个讨厌之处在于限制，一个int值有32个位置，long有64个，可权限却可能更多，尤其是每种资源操作不同。
有时候我可以考虑重用位置，比如第二位在资源A上表示一种操作，资源B上表示另一种。
当然这又重新带来了复杂度，比如要求设计时避免将来可能产生的重叠和不一致，需要小心维护它们。
（考虑这将导致对于同一用户，两种资源的两个不同操作权限只能是同步的）
实际上这是因为受限于持久层软件的能力才产生的。可想如果持久层是自己的，那自由度就高很多。
很遗憾这不太可能，尤其是权限系统的独立也不太可能（因为总会存在联合操作的需求，比如某种查询）。
那么使用更大位数的字段或者更多的相同类型的字段（根据数据库软件的特性选择），是一个替代共享的方案吗？
我觉得行，但是没有时间和机会去验证这个。
有一点是可以确定的，即便是1024种操作也不过是32个int，数据量的控制还是不错的。
当然，还有一种方式是干脆用更多的连接表来展开用户、组、资源、操作之间的全部关系，这在关系模型的能力之内。
或者结合设计：对于（资源类别、用户）对，有一个唯一对应的bit组或其他编码形式说明各个操作。
我觉得具体的做法还是需要根据项目来，这似乎是废话，不过实际上思路也是有限几种。
无论是整体设计还是细节，恐怕都不能统一到某一种绝对占上风的方式上，不过还是有些建设性的探索工作可以做。
这就是找出不同的方式和不同场景其特征之间的对应关系。
这才是重用的基础。至于标榜某种做法“优胜”，或者是仅简简单单的说它“够用”，个人不敢苟同。
一些想法，欢迎大家讨论。