与传统开发的思考点不同，在SaaS中，可能更多考虑的是数据隔离（在这里考虑共享数据库，共享数据表），数据通用方面
租户id
既然是SaaS平台，那么肯定是多租户的一个生态。那么在数据库层面，一定要有一个字段来隔离数据。
这个字段在每个表都需要有，且每一次数据库的操作都需要有该字段作为条件。
这一步数据安全的控制都放在了代码中，所以安全性和隔离性都是要依赖编码的。
表的自增id
这个字段还是要有的，但是强烈建议不要在删除行数据，查询数据，修改数据时使用到该字段，因为该字段的单独操作会破坏掉数据的隔离性。也就是前面所说的，所有的sql操作，都要带上租户id再进行。
数据来源标识
作为SaaS平台，在很多情况下，不同的租户可能有一样的数据，或者是通过某些编程，或者是通过配置的方式，通过一套标准数据生成了各个租户的数据。可以实现租户的自定义。
但是在某些情况下，可能某个特性不需要租户进行自定义，而是SaaS系统进行一个控制，那么就需要一个标识，来知道这个数据来源一致。
需要确定的是，这个标识，在这个租户下是唯一的。也就是说，前面的自增id没有用，但是这个标识和租户的id是可以唯一索引到一条数据的。
强烈建议使用租户id和数据的来源标识进行操作数据。
元数据
元数据用一句话就是描述数据的数据
在SaaS中，存在着一些通用配置，通过这些通用配置，可以自由定义一些业务模型，可以极其快速的实现业务需求。
简单的说几句，元数据能用非关系型数据库就不要用关系型数据库。前期量级小的时候问题，后面访问量，压力很大。
其次，通用的一些业务模型，一定要抽取出来。元数据对业务来说是极其基础的存在的，业务不应该感知到元数据的存在。业务感知的应该是元数据的一些业务组合，也就是业务模型。
通过组装业务模型，可以配合不同的业务场景，最后实现业务功能。
租户数据
租户的数据，是基于一些元数据来生成的，所以是可扩展的。在这里，也建议不要使用关系型数据库，因为不太适合，非关系型数据库更加适合SaaS系统这个体系。
如果要做SaaS系统，一定要考虑长远，不要先被业务拖累。如果在半年一年内无法脱离业务需求来架构设计与开发SaaS系统，那么我的建议是，不要做什么SaaS了，开发业务吧，不然公司都活不下去的。
网友评论