SaaS可配置化:数据可配置化

11 评论 23910 浏览 114 收藏 5 分钟

针对SaaS多租户模型,本文分析了如何实现拓展数据的可配置。

针对SaaS多租户模型,在实际运行过程中会发现不同的租户需要保存不同的特殊字段。

例如,就拿CRM系统而言,A租户希望能保存客户纪念日、来源等,而这些数据对应B租户而言并不需要。

这种系统实现过滤中并不存在,而用户又需要被保存的数据,称为拓展数据。显然,不同的客户需要保存的拓展数据可能是完全不同的。

对拓展数据的处理,在传统模式中是完全不存在问题的,因为传统软件模式一个客户对应一套软件及数据库实例,系统可是实现根据客户的要求定制化数据库实例。

但在SaaS模式,多个客户对应同一套实例,如依旧采用传统定制化模式,数据库必将产生大量多余的字段,进而影响数据的性能。

针对SaaS多租户模型,对于拓展数据,最常见的解决方案就是实现拓展数据的可配置,包含如下三种主流的解决方案。

一、定制字段

该解决方案更多还是在传统软件中被采用,根据用户的实际需求,在数据表中增加相应的字段。 如系统只有一个用户,那么定制字段可以完美的满足用户及技术需要。

但针对SaaS对租户模型,如还为每一个客户都添加字段,那么势必会使表中字段多如牛毛,而且随着定制字段的增多,将产生大量无意义字段,严重影响数据库性能。

二、预分配字段

预分配的实现逻辑就是在设计数据表结构时,预留设计多几个无意义的字段,根据实际运行过程所需的业务要求,为对应的字段赋予实际的业务意义。

例如A客户需要额外留存订单号,那么预分配A字段的对于A客户而言保存的就是订单号,B客户需要额外需要座机号,那么预分配A字段对应B客户而言就是座机号。

预分配字段在一定程度满足租户对于拓展数据的需求,但并不是完美的解决方案,依旧存在如下不足点:

  • 可拓展性差:预分配字段数无法实时把控,预分配字段解决模式需要在数据库设计前期就设定好预留的字段个数,预留多了容易造成浪费,预留少,不够拓展使用。
  • 数据类型难把控,对于预分配位置,可能需要存储字符类型,也可能需要存储日期类型,具体的类型无法把控。当然,也可以统一存成字符类型,在根据实际的业务要求,在代码逻辑中实现类型的转化。

三、名称值对

引入配置元数据表的概率,数据库表分为拓展数据表、业务数据表、配置元数据表。

业务数据表负责存储统一 的业务逻辑数据,拓展数据表存储根据租户需求而新增的拓展数据,而拓展数据表与业务数据表通过元数据配置表关联。引入元数据噢诶子表,实现拓展数据的横向拓展,而且完全由租户业务驱动,不造成数据的浪费及混乱。

诚然,不管是定制字段,预分配字段还是名称值对,所针对的都是数据库的设计。

本文主要还是介绍产品人员怎样构建SaaS应用,对于涉及偏向技术性的问题,这里只大致介绍一下,有兴趣的小伙伴可以自行查找相关资料就行了解。

 

本文由 @老鬼 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 Unsplash ,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 如果能运用在低代码平台,那是不是可以解决定制字段的问题

    来自安徽 回复
  2. 赞! 名值对看似灵活 也固然有其不足。尤其进行一些统计查询时

    来自天津 回复
  3. 您好,非常感谢!我们现在就是采用的这个方式,只是评审的时候,每个租户的表单字段不一致,前端需要写N个页面,这个有什么解决办法吗

    回复
    1. 把不同租户的表单进行抽象,进行组件化和模版化,再根据不同租户单独配置不同的表单样式

      来自广东 回复
  4. 点赞点赞!
    有接触过预分配字段,当时感觉有点蠢…但是没想到‘名称值对’这种方案…

    来自江苏 回复
  5. 有没有第三方的专门做数据和权限配置的服务商?

    来自上海 回复
    1. 同求

      来自北京 回复
  6. 最近碰到的问题是怎么实现后台可配置点和后台接口的灵活标准

    来自浙江 回复
  7. 文章所做的小结非常有阅读价值,希望作者能就Saas系列写出更多文章

    来自浙江 回复
  8. 期待作者详细说下第三种方案-名称值对,目前SaaS产品中做的最火热的应该就是美国的salesforce CRM产品了,他们是否也是通过该方案呢

    来自上海 回复
  9. 意犹未尽,刚好最近思考后台如何在灵活性下保证前台的用户体验。

    回复