SaaS预研-表单属性可配置方案

背景

在SaaS多租户模型里，首先要确认在其行业背景下，通用的行业内标准数据字段，这些字段是行业内都认知一致场景描述字段。这些字段将设计参与系统的功能逻辑中，如果用户使用的是这些字段，要提供给用户字典查询功能，告诉用户系统内已经包含该字段，如果意义一样，可以直接使用。其次是针对SaaS多租户模型，在实际运行过程中会发现不同的租户需要保存不同的特殊字段，这些字段相对于系统而已属于用户的个性化差异字段，只针对于当前用户有意义，这种字段称之为拓展数据，拓展数据属于未知功能需求，而且多样化，解决这一问题，首选的方案就是针对于这些字段实现可配置化。可配置化的优势在于可以快速而且稳定实现用户的个性化拓展数据的需求，减轻甚至不用依赖于系统功能迭代来实现，当然可配置化的程度还是要取决于用户实际的功能需求。这里配置分成两种，用户配置合系统配置，用户配置指用户自己通过系统配置的功能配置就可以使用，系统配置指用户需要将需求提交给我们，由我们配置生成相应的功能，然后交付给用户。

功能需求

1. 拓展数据主要实现其特性业务的描述功能，不需要查询统计等功能，跟系统的已设计的业务功能没有耦合。
2. 拓展数据在实现其特性业务的描述功能同时需要查询统计等功能，跟系统的已设计的业务功能没有耦合。
3. 拓展数据在实现其特性业务的描述功能同时需要查询统计等功能，也需要跟系统的已设计的业务功能有一定程度耦合。

解决方案

根据以上不同的功能需求，这里整理了以下几种解决方案。

一、 定制字段

该解决方案更多还是在传统软件中被采用，根据用户的实际需求，在数据表中增加相应的字段。

实现方式

通过搜集用户需求，迭代功能发布的方式实现。用户可配置程度为0，系统可配置程度为0，

优点

逻辑简单，实现简单，可以很好的支持查询统计等功能，因为是通过功能迭代发布实现，也可以实现与已设计的业务功能耦合。

缺点

只能针对于单一用户或多用户下的单一业务场景（即用户都有此需求），当面对不同用户的不同场景时，每一个用户都添加字段，那么势必会使表中字段多如牛毛，而且随着定制字段的增多，将产生大量无意义字段，严重影响数据库性能或者因耦合的业务逻辑太多导致的业务混乱，后期开发维护成本高，对系统的稳定性造成较大影响，通过迭代发布，实现周期长。

二、 预分配字段

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

实现方式

系统针对于主要业务表预留字段，系统提供配置界面，用户根据其业务需求自行配置，

然后对应的功能根据用户的配置，展示，使用这些预留字段。用户配置程度80%，系统配置程度0%

优点

由用户自行配置，灵活简单，快速，且支持特定的查询统计等功能，实现该功能复杂度较低，可以面向多用户多场景，维护运营成本低。

缺点

可拓展性差：预分配字段数无法实时把控，预分配字段解决模式需要在数据库设计前期就设定好预留的字段个数，预留多了容易造成浪费，预留少，不够拓展使用。

数据类型难把控，对于预分配位置，可能需要存储字符类型，也可能需要存储日期类型，具体的类型无法把控。当然，也可以统一存成字符类型，在根据实际的业务要求，在代码逻辑中实现类型的转化。无法跟系统已经设计好的功能进行耦合，查询统计等功能会比较固定。

三、 名称值对

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

业务数据表负责存储统一 的业务逻辑数据，拓展数据表存储根据租户需求而新增的拓展数据，而拓展数据表与业务数据表通过元数据配置表关联。引入配置元数据子表，实现拓展数据的横向拓展，而且完全由租户业务驱动，不造成数据的浪费及混乱，同时也可以通过元数据表进行耦合和解耦系统已设计的业务功能。

实现方式

收集用户需求，建立扩展数据表，配置元数据表（或配置文件），通过关联业务数据表，配置元数据表，扩展数据表，在对应的功展示和使用拓展数据。拓展数据跟业务数据会分成独立的块来展示和使用，可以通过元数据表配置耦合或解耦系统已设计的功能。通过功能迭代的方式发布实现。用户可配置度0，系统可配置度100%

优点

可扩展性强，支持筛选统计，以及一些相应的业务逻辑。由于通过配置实现，跟系统耦合性低，一个客户也可以支持不同的业务场景的配置，或者不同的用户也可以共用同一套配置。

缺点

通过迭代发布，周期长，开发运营成本高，不能实时灵活配置。

四、 名称值对改进

原理同名称值对方式，也是由扩展数据表、业务数据表、配置元数据表组成。

但实现方式不同。

实现方式

系统会提供一个扩展数据配置引擎，提供配置操作功能界面，用户在此界面选择要配置的业务数据表，然后配置自己需要的字段及数据类型，配置信息将保存到配置元数据表，同时如果判断扩展数据表未存在，则根据配置好的字段信息，直接动态生成该表，并同时配置好基于该表的基本的增删改查功能，还要生成一个该表的配置文件，在配置的功能实现使用引擎中，在增删改查等前后点增加面向切面的事件回调处理机制。在用户配置好了基本的扩展数据后，如果没有耦合已有系统功能的需求，则可以直接使用，如果有用户指定其中的字段跟现有的系统进行耦合，并将这些耦合的规则提供给我们，我们将在版本迭代中帮用户完成这些耦合。用户配置度80%，系统配置程度：60%

优点

可配置性强，在用户没有需要耦合已有业务功能需求下，用户可根据需要自行灵活快速配置需要的扩展数据，并支持查询统计等功能。如果用户有耦合已有业务的需求，但允许我们系统通过迭代发布的方式帮助其实现其功能的前提下，也能很好支持用户的耦合已有业务功能的需求。

缺点

功能实现上要更为复杂，如果用户有耦合已有业务功能的需求需要通过系统迭代发布，完整实现用户的需求，需要有等待周期，如果这种耦合已有业务功能的需求过多，需要大量的开发成本。

喜欢的朋友记得给关注~