低代码如何设计高效的数据模型？

本文作者：得帆信息aPaaS业务线副总裁石雨田

低代码开发平台（LCDP/LCAP）作为数字化转型的关键工具，通过可视化编程和模块化开发，显著降低了软件开发的复杂性，缩短了应用交付周期。其核心优势在于能够快速响应业务需求的动态变化，从而提升企业的敏捷性和竞争力。然而，低代码平台的性能和扩展性不仅依赖于开发工具的易用性，更取决于其底层数据模型的设计。

数据模型是低代码平台的核心组件，它定义了数据的结构、关系和约束，直接影响平台的易用性、性能和扩展性。合理设计的数据模型能够高效组织数据，保障数据一致性，并为快速开发提供支持。

本文将深入探讨低代码平台中常见的数据模型设计方案，分析其技术特点、适用场景及优劣势，为选择合适的数据模型提供参考。

低代码内的数据主要划分为两类

一类是以声明式配置存储为核心的各类配置数据存储。

一类是以业务数据存储为核心的各类业务数据的存储【本文核心讨论此类数据的存储模型设计】。

业务数据存储的几种方式

一般来说低代码平台的业务数据存储设计包含以下几种方式：

• 基于数据库表存储
• 基于文档数据库存储
• 基于大宽表+扩展字段存储

01基于数据库方式

基于数据库的方式存储是日常开发中最常见的方式，通过设计数据模型，将业务数据存储在实体表中。

低代码采用此方式通过ddl动态列的方式实现：

• 模型新增和修改时：在低代码中修改和增加数据模型时，通过ddl语句的方式来实现数据库动态列的修改。
• 数据操作时：通过动态实体或动态sql的方式进行数据操作，最终数据操作和使用常规spring boot等开发完全一致

此方式的优点：

和常规开发对于数据库操作完全一致，易于开发理解，可以良好的支持运维和优化。

可以接入历史数据，快速迁移使用历史应用。

使用灵活性强，除了支持低代码默认的CRUD方法外，还可以自定义扩展各类的开发，通过编写使用自定义SQL实现业务。

可以支持现有数据库表和视图反向生成数据模型，映射相关字段。实现现有系统的快速接入。

（5）基于此模式在大量数据的时候，可以依赖数据库表结构增加索引等方式快速的优化访问。

（6）方便支持多数据源模式，可以接入外部数据源。

此方式的缺点：

实现方案较为复杂，需要支持动态实体或动态sql的方案。

对接不同的数据库需要支持不同的方言和兼容模式。

ddl语句存在一定的限制，如mysql最大列宽65535，这时候需要在产品设计上支持分表的逻辑。

数据库权限要求比较高，需要支持ddl语句。

（5）ddl在大数据量时执行锁表，如变更列类型时最好使用新增列，更新列，再删除历史列的方式来执行。

针对以上方案中的ddl可能存在的问题，可以通过以下管理方式来解决：

针对 mysql 语句最大列宽等问题：支持在拖拉拽沟通模型的时候，支持数据模型长度过长的提示，支持手动或者自动的方式拆分为多张1：1的关联表来实现。

针对数据库权限有些情况下不适合ddl语句的情况，可以在测试环境放开权限执行变更，生产环境上线时，采用类似liquibase等数据版本管理机制，在发布生产时统一检查处理。

此方案实现较其他方案相比复杂的多，但为了和传统开发一样具备良好的可读性和易运维性，在复杂系统性能指标和调优时能借助数据库上丰富的能力和经验，这个方案是最优解，另外此方案也能支撑历史系统快速接入低代码平台。

02基于文档数据库模式

基于类似mongodb等文档数据库来存储业务数据，也是低代码平台的另一个选择。这种情况下用户大多无需关注数据模型，通过自动创建collection和field来实现表和字段的动态增减。

此方式的优点：

实现简单，依赖文档数据库的灵活性实现。

用户体验好，用户只需要关注前端拖拉拽界面，所见即所得，无需关注数据模型变化。

查询体验不错，mongodb作为文档型数据库，本身就是以查询速度见长，在大量数据简单查询的情况下，无需任何优化体验很不错。

此方式的缺点：

由于文档模型提供的配置灵活性，在同一个collection下多次删减字段，可能会导致数据结构的混乱。

无法支持和外部数据源对接，一般情况下只能通过暴露接口或者etl工具进行内外部的数据交互。

mongodb作为业务数据存储的情况在国内还没有普及，缺乏专业的运维知识和经验，另外国内信创情况下文档数据库也非首选。

自开发扩展上也需要使用mongo等数据查询，因为mongo数据库的灵活性，需要在自开发时先获取当前meta元数据再进行开发，开发的成本比较高。

借助于文档数据库的灵活性，此方案非常适合一些轻量级的低(无)代码平台，在新建表单和数据拖拽时有非常良好的体验。数据交互的部分，如果数据量不大的情况下，全部使用API交互也是系统构建的通用逻辑，所以此方案在轻量级的应用场景下也是不错的选择。

03基于大宽表 + 扩展字段设计模式

这种方案其实最开始来源于ERP产品的设计，在早期为了方便扩展会增加各个类型的扩展字段15-20个。在低代码的初期也有一些按照此方式实现的案例。主要分为2种，一种是都存在一个表里面，另外一种是预置一组表结构，每个实体一张表。

此方式的优点：

表已经预置好，无需动态ddl语句支持。

可以适用数据库复杂sql的所有逻辑。

灵活性也比较好，支持动态字段映射，支持所见即所得的模式。

此方式的缺点：

可读性比较差，完全需要配合元数据使用。

数据冗余太多，和界面上数据的对应关系需要额外维护元数据绑定。

针对数据库层面的约束，如唯一索引，非空等设置需要在应用层实现。

无法接入现有数据源。

实际上此方案从设计逻辑上来讲，通过充分的冗余来实现业务的灵活性，也兼顾了技术角度的性能，实际上在类似ERP这种稳固的表结构上增加扩展非常合适。

在低代码平台上，这个方案可读性和可运维性太差，针对每张表在实际运维的时候需要速查表。

在全部云端(无私有化部署)的情况下，可以用通用的运维团队，依赖一些通用工具来实现业务的管理实现，但是私有化情况下，交付给客户的运维团队使用，基本上不太可能实现。

总结：上述方案的使用情况

（1）【最优】在技术和资源允许的情况下，建议使用方案一【基于数据库表存储】。通过复杂的技术实现拥有最好的兼容性和扩展性，也是唯一一个支持直接快速接入历史应用数据的方案。

（2）在轻量级应用场景，可以使用方案二【基于文档数据库存储】，借助文档数据库的能力快速实现低代码化。

（3）在SaaS场景和集中式运维的场景下，可以采用方案三【基于大宽表+ 扩展字段存储】来实现低代码平台，甚至可以在上面开发一系列的衍生工具，如CRUD API，如基于元数据构建查询视图等。

系统字段设计规范：标准系统字段

在系统开发过程中为了标注数据的使用规范，权限规范，通用逻辑等，为业务表增加通用的系统字段，本身也是一个健壮的系统的初始架构，一般来说低代码平台也会有相关的系统字段。

以下以得帆低代码平台举例：

低代码中数据存储的模式和方法，将极大影响企业日常低代码系统运营效率和业务发展效率。如有您想了解更多信息，欢迎联系得帆顾问，我们将真诚为您排忧解难。