在公司做了一年的SaaS內核系統，但是有些東西不知道能不能透露出來。我儘量在不透露一些敏感東西的情況下（這個度我無法把控，只能是籠統了），將某些關於數據庫方面的精髓傳遞出來。如果表達不暢，請諒解。
前面的兩篇講解了在傳統系統和大數據量下的數據庫設計應該注意的事項。
接下來需要換一種思路，在SaaS系統中，數據庫應該如何進行設計。
與傳統開發的思考點不同，在SaaS中，可能更多考慮的是數據隔離（在這裡考慮共享數據庫，共享數據表），數據通用方面
租戶id
既然是SaaS平臺，那麼肯定是多租戶的一個生態。那麼在數據庫層面，一定要有一個字段來隔離數據。
這個字段在每個表都需要有，且每一次數據庫的操作都需要有該字段作為條件。
這一步數據安全的控制都放在了代碼中，所以安全性和隔離性都是要依賴編碼的。
表的自增id
這個字段還是要有的，但是強烈建議不要在刪除行數據，查詢數據，修改數據時使用到該字段，因為該字段的單獨操作會破壞掉數據的隔離性。也就是前面所說的，所有的sql操作，都要帶上租戶id再進行。
數據來源標識
作為SaaS平臺，在很多情況下，不同的租戶可能有一樣的數據，或者是通過某些編程，或者是通過配置的方式，通過一套標準數據生成了各個租戶的數據。可以實現租戶的自定義。
但是在某些情況下，可能某個特性不需要租戶進行自定義，而是SaaS系統進行一個控制，那麼就需要一個標識，來知道這個數據來源一致。
需要確定的是，這個標識，在這個租戶下是唯一的。也就是說，前面的自增id沒有用，但是這個標識和租戶的id是可以唯一索引到一條數據的。
強烈建議使用租戶id和數據的來源標識進行操作數據。
元數據
元數據用一句話就是描述數據的數據
在SaaS中，存在著一些通用配置，通過這些通用配置，可以自由定義一些業務模型，可以極其快速的實現業務需求。
這個元數據，我正在公司負責這塊，但是可能不能透露。
簡單的說幾句，元數據能用非關係型數據庫就不要用關係型數據庫。前期量級小的時候問題，後面訪問量，壓力很大。
其次，通用的一些業務模型，一定要抽取出來。元數據對業務來說是極其基礎的存在的，業務不應該感知到元數據的存在。業務感知的應該是元數據的一些業務組合，也就是業務模型。
通過組裝業務模型，可以配合不同的業務場景，最後實現業務功能。
租戶數據
租戶的數據，是基於一些元數據來生成的，所以是可擴展的。在這裡，也建議不要使用關係型數據庫，因為不太適合，非關係型數據庫更加適合SaaS系統這個體系。
其實東西很多，但是暫時先講到這了，我也不知道某些東西是不是屬於公司的，前些日子我們公司剛爆出了員工透露公司機密到網上，所以。。。
最後講下吧，如果要做SaaS系統，一定要考慮長遠，不要先被業務拖累。如果在半年一年內無法脫離業務需求來架構設計與開發SaaS系統，那麼我的建議是，不要做什麼SaaS了，開發業務吧，不然公司都活不下去的。
整篇看上去會比較理論，但是實際上，這些都是實踐後的一些理論點。有很多的一些東西，我無法分享太多，非常抱歉。這次也是借這個阿里雲活動的機會，分享一點出來。