作为后端开发如何设计数据库系列文章设计SaaS系统表结构

在公司做了一年的SaaS内核系统，但是有些东西不知道能不能透露出来。我尽量在不透露一些敏感东西的情况下（这个度我无法把控，只能是笼统了），将某些关于数据库方面的精髓传递出来。如果表达不畅，请谅解。

前面的两篇讲解了在传统系统和大数据量下的数据库设计应该注意的事项。

接下来需要换一种思路，在SaaS系统中，数据库应该如何进行设计。

与传统开发的思考点不同，在SaaS中，可能更多考虑的是数据隔离（在这里考虑共享数据库，共享数据表），数据通用方面

租户id

既然是SaaS平台，那么肯定是多租户的一个生态。那么在数据库层面，一定要有一个字段来隔离数据。

这个字段在每个表都需要有，且每一次数据库的操作都需要有该字段作为条件。

这一步数据安全的控制都放在了代码中，所以安全性和隔离性都是要依赖编码的。

表的自增id

这个字段还是要有的，但是强烈建议不要在删除行数据，查询数据，修改数据时使用到该字段，因为该字段的单独操作会破坏掉数据的隔离性。也就是前面所说的，所有的sql操作，都要带上租户id再进行。

数据来源标识

作为SaaS平台，在很多情况下，不同的租户可能有一样的数据，或者是通过某些编程，或者是通过配置的方式，通过一套标准数据生成了各个租户的数据。可以实现租户的自定义。

但是在某些情况下，可能某个特性不需要租户进行自定义，而是SaaS系统进行一个控制，那么就需要一个标识，来知道这个数据来源一致。

需要确定的是，这个标识，在这个租户下是唯一的。也就是说，前面的自增id没有用，但是这个标识和租户的id是可以唯一索引到一条数据的。

强烈建议使用租户id和数据的来源标识进行操作数据。

元数据

元数据用一句话就是描述数据的数据

在SaaS中，存在着一些通用配置，通过这些通用配置，可以自由定义一些业务模型，可以极其快速的实现业务需求。

这个元数据，我正在公司负责这块，但是可能不能透露。

简单的说几句，元数据能用非关系型数据库就不要用关系型数据库。前期量级小的时候问题，后面访问量，压力很大。

其次，通用的一些业务模型，一定要抽取出来。元数据对业务来说是极其基础的存在的，业务不应该感知到元数据的存在。业务感知的应该是元数据的一些业务组合，也就是业务模型。

通过组装业务模型，可以配合不同的业务场景，最后实现业务功能。

租户数据

租户的数据，是基于一些元数据来生成的，所以是可扩展的。在这里，也建议不要使用关系型数据库，因为不太适合，非关系型数据库更加适合SaaS系统这个体系。

其实东西很多，但是暂时先讲到这了，我也不知道某些东西是不是属于公司的，前些日子我们公司刚爆出了员工透露公司机密到网上，所以。。。

最后讲下吧，如果要做SaaS系统，一定要考虑长远，不要先被业务拖累。如果在半年一年内无法脱离业务需求来架构设计与开发SaaS系统，那么我的建议是，不要做什么SaaS了，开发业务吧，不然公司都活不下去的。

整篇看上去会比较理论，但是实际上，这些都是实践后的一些理论点。有很多的一些东西，我无法分享太多，非常抱歉。这次也是借这个阿里云活动的机会，分享一点出来。

原文链接
本文为云栖社区原创内容，未经允许不得转载。