自动化平台中的ORM和权限设计

最近在梳理平台里的一些基础架构和设计，力争把平台里的通用的部分能够抽象出来，迭代复用。

在数据库设计上我秉承了从简的原则，如果能用一个表搞定，我绝对不会把它拆分成多个表。对于概览信息，其实设计上是需要考虑冗余信息的，哪怕看起来不是那么的精美。但是用起来就是直接。而我绝不会只设计一个表，如果需要扩展的，毫无疑问，我会拆分出另外的表来。对于原来的结构设计几乎没有什么影响。

第二个是对于Django的ORM，我最近也实现了一些功能和页面，在实践中我发现，使用原生的ORM来显式声明大量的关联关系其实会引入大量的外键设计，这对于数据库设计来说，反而是略显丑陋的。这部分的内容其实完全可以通过程序端的逻辑来控制。

当然在这个基础上，一个很明显的问题就是如何理解ORM的使用边界，我的使用实践更倾向于是使用原生的model设计，但是外键关联和多表关联，我都是通过逻辑层来统一控制，具体怎么控制，我是抽象出一个DAO层，把这部分逻辑放到这里面来，这样一来，我要定制多对多的关系，指定n多个辅助字段都是手到擒来，这样一来就会从已有的桎梏中解放出来。

而在这个基础上，我们使用ORM的一个优点就是数据源的透明，但是需要理解的是，我们说的透明，其实不代表数据迁移，所以你引入了一些定制的其他数据库的SQL语句，如果语句符合SQL规范，其实是没有什么问题的，除非是数据库特有的语句。这些如果都抽象到一个DAO层中，这个事情其实就好做多了。

对于权限设计，我是这样考虑的。一个最粗粒度的权限就是基于菜单级别，就是不同的用户看到的菜单应该不同。这是最基本的要求。

在这个基础上进行扩展，我们可以定制不同的角色组，比如MySQL组，Redis组，不同的组看到的同一个菜单中的数据也可以不同。

同时，对于数据的增删改查，我们可以通过菜单级别来控制，如果没有修改权限，用户就不应该看到这个菜单。