针对SaaS多租户模型，在实际运行过程中会发现不同的租户需要保存不同的特殊字段，例如，就拿CRM系统而言，A租户希望能保存客户纪念日，来源等，而这些数据对应B租户而言并不需要。这种系统实现过滤中并不存在，而用户又需要被保存的数据，称为拓展数据。显然，不同的客户需要保存的拓展数据可能是完全不同的。

　　对拓展数据的处理，在传统模式中是完全不存在问题的，因为传统软件模式一个客户对应一套软件及数据库实例，系统可是实现根据客户的要求定制化数据库实例。但在SaaS模式，多个客户对应同一套实例，如依旧采用传统定制化模式，数据库必将产生大量多余的字段，进而影响数据的性能。

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

　　1：定制字段

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

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

　　2：预分配字段

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

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

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

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

　　3：名称值对

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

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

　　诚然，不管是定制字段，预分配字段还是名称值对，所针对的都是数据库的设计，本文主要还是介绍产品人员怎样构建SaaS应用，对于涉及偏向技术性的问题，这里只大致介绍一下，有兴趣的小伙伴可以自行查找相关资料就行了解。

　　责任编辑:DJ编辑