自動化平臺中的ORM和許可權設計

最近在梳理平臺裡的一些基礎架構和設計，力爭把平臺裡的通用的部分能夠抽象出來，迭代複用。

在資料庫設計上我秉承了從簡的原則，如果能用一個表搞定，我絕對不會把它拆分成多個表。對於概覽資訊，其實設計上是需要考慮冗餘資訊的，哪怕看起來不是那麼的精美。但是用起來就是直接。而我絕不會只設計一個表，如果需要擴充套件的，毫無疑問，我會拆分出另外的表來。對於原來的結構設計幾乎沒有什麼影響。

第二個是對於Django的ORM，我最近也實現了一些功能和頁面，在實踐中我發現，使用原生的ORM來顯式宣告大量的關聯關係其實會引入大量的外來鍵設計，這對於資料庫設計來說，反而是略顯醜陋的。這部分的內容其實完全可以透過程式端的邏輯來控制。

當然在這個基礎上，一個很明顯的問題就是如何理解ORM的使用邊界，我的使用實踐更傾向於是使用原生的model設計，但是外來鍵關聯和多表關聯，我都是透過邏輯層來統一控制，具體怎麼控制，我是抽象出一個DAO層，把這部分邏輯放到這裡面來，這樣一來，我要定製多對多的關係，指定n多個輔助欄位都是手到擒來，這樣一來就會從已有的桎梏中解放出來。

而在這個基礎上，我們使用ORM的一個優點就是資料來源的透明，但是需要理解的是，我們說的透明，其實不代表資料遷移，所以你引入了一些定製的其他資料庫的SQL語句，如果語句符合SQL規範，其實是沒有什麼問題的，除非是資料庫特有的語句。這些如果都抽象到一個DAO層中，這個事情其實就好做多了。

對於許可權設計，我是這樣考慮的。一個最粗粒度的許可權就是基於選單級別，就是不同的使用者看到的選單應該不同。這是最基本的要求。

在這個基礎上進行擴充套件，我們可以定製不同的角色組，比如MySQL組，Redis組，不同的組看到的同一個選單中的資料也可以不同。

同時，對於資料的增刪改查，我們可以透過選單級別來控制，如果沒有修改許可權，使用者就不應該看到這個選單。