这是一个创建于 410 天前的主题，其中的信息可能已经有所发展或是发生改变。
叠个甲：Java 没写多久，可能这个问题有现成的解决方案，但是我找了很久没找到
目标： 找到一个最简单最通用的框架/方法，来实现对自定义表(没有实体)的通用增删改查操作。
前提：
0.项目内有两种类型的表，一种是预置的表，比如用户表，菜单表。还有一种是在项目发布不清楚数据结构，用户自定义的表。但是每个表都有一些固定的字段，比如id,create_at等，可以有一个基类，但是更多的还是不同的业务字段。
1.用户可以自定义表以及表内的字段信息，这种表一般来说固定好了之后很少会修改。用户会在项目中配置（有配置页面）有哪些表，每个表有哪些字段。
想法：
0.最底层的方法，写一个 XML ，里面有一系列的通用的方法，比如(select {field_list} from {table_name} where {query_condition})然后每次查询的时候把所有的需要的信息丢进去。
好处：肯定可以实现功能 缺点：比较繁琐
1.找到一个方法，去生成类似于实体概念的一个玩意儿，然后后续就是对接到现有的 Mybatis 等框架上。
2.找各位大佬寻求建议
第 1 条附言 2024-08-29 16:28:54 +08:00
补充一下，我说的表并不是用户表这种可以用 MP 直接生成代码的表，这种确实可以用代码生成器在写代码的时候生成对应的 Service 和 Mapper 。
但是现在的问题是我并不清楚具体的模型，模型在代码开发时是未知的。所以我并不能使用代码生成器在代码开发阶段就将第二种类型的表生成对应代码
要明确一下出现的时机。显示完成代码编写，然后发布。第二种类型的表的出现时间在项目发布之后才能确定。A 部署的时候可能是 A 表及相应的字段，B 部署的时候可能是 B 表及相应的字段，无法确定
但是现在的问题是我并不清楚具体的模型，模型在代码开发时是未知的。所以我并不能使用代码生成器在代码开发阶段就将第二种类型的表生成对应代码
要明确一下出现的时机。显示完成代码编写，然后发布。第二种类型的表的出现时间在项目发布之后才能确定。A 部署的时候可能是 A 表及相应的字段，B 部署的时候可能是 B 表及相应的字段，无法确定
 | 1 lnbiuc 2024-08-29 16:04:03 +08:00 你是否在找一个低代码平台，以下内容参考金蝶低代码平台： 定义一个动态对象，包含实体标识、数据库表名、分库标识等等，包含数据存储，底层是 Map ，key 为字段标识，val 为对象，中包含数据库字段名，类型等信息。每次查询时通过实体标识先查到动态对象类型，获取到对象有的字段，然后根据这些信息拼接出 SQL ，直接去数据库执行，获取 ResultSet ，自行转换成前面的动态对象，补充缺失信息。取值赋值就取 Map 再取 key 。保存更新也是一样的道理，拼接出 SQL 执行。 这样除了数据表，至少还有一个实体数据表，存储数据表的数据结构 |
 | 2 mawen0726 2024-08-29 16:12:20 +08:00 https://baomidou.com/ mybatis-plus 不知道是否符合你 |
 | 3 tongjiann OP @mawen0726 #2 不是，这个是需要提前知道模型信息并将实体定义在代码中，我这里在设计代码时并不知道具体的模型信息 |
 | 4 langzibing 2024-08-29 16:20:17 +08:00 用反射和泛型 |
 | 5 functionABC 2024-08-29 16:22:09 +08:00 你说的事自己在系统上维护表，然后将模型生成到数据库表中，然后自动生成表需要的实体和其他代码。是不是这样，mybatisplus generator 了解下 |
| 6 langzibing 2024-08-29 16:22:54 +08:00 而且你说的用 mybatis-plus 就可以实现啊，用户自定义表不就是生成表和修改表字段吗，再调用 gene 生成实体不就是你想要的结果 |
 | 8 duanxianze 2024-08-29 16:28:34 +08:00 你要找的实际是 nosql,可以随意存放数据，简单搞的话就用 mysql 直接存 json ，现代数据库可以直接操作 json 对象 |
| 9 tongjiann OP  1 @duanxianze #8 客户提供了数据源及字段信息，我需要借助 JAVA ，将客户提供的数据源以列表的形式展示在我的系统的某一个页面中，并提供增删改查功能 |
 | 10 vacuitym 2024-08-29 16:32:37 +08:00 做过一次类似需求的，一个支付相关的配置表，由于不同渠道的配置不一样，我们是基于一个基础表然后给基础表增加了一个 text 的字段存储 json 信息，然后另一张字典表来定义这个 json 有哪些字段 |
| 11 duanxianze 2024-08-29 16:33:55 +08:00 @tongjiann 对啊 我说的就是这个意思，你可以直接把不固定的字段序列化成 json 存到一个字段里就行了，利用 json 相关的函数一样可以增删改查 |
 | 12 mercurylanded 2024-08-29 16:34:41 +08:00 java 搞这种麻烦，换 js 或者 python 吧 |
 | 13 java20 换 mongo 数据库 |
 | 14 Mandelo 2024-08-29 16:37:41 +08:00 mybatis generator+freemarker 之类的模板,别说接口了,前台 vue 页面都能给你一条龙生成 |
 | 15 sagaxu 2024-08-29 16:42:56 +08:00 用户会在项目中配置（有配置页面）有哪些表，每个表有哪些字段。 如果没配置字段类型，可以在首次载入时去 db 里查表结构。 根据表名，字段名，字段类型，生成对应的 SQL 不麻烦吧。 这根本就不需要什么框架。 |
 | 16 zoharSoul 2024-08-29 20:01:52 +08:00 1 不要搞这种东西 |
 | 17 doublestart 2024-08-29 21:20:51 +08:00 完全可以借鉴低代码的思想, 比如第 1 点: 用户会在项目中配置（有配置页面）有哪些表，每个表有哪些字段。 这个只是把数据库建表工具通过网页来做而已, 低于基本增删改查完全够用了, 如果有点复杂的逻辑, 必定要生成对应的实体类才行 |
 | 18 lower 2024-08-29 22:25:38 +08:00 1 这基本就是低代码，我看了一下某个项目的查询这块的实现，是用的 MyBatis Dynamic SQL ，根据记录的自定义表信息，表单信息，列信息，查询信息配置等，组装 MyBatis Dynamic SQL 需要的 Provider 。。。本质就是手动拼 sql ，只不过这个组件封装了拼的过程，能帮你减少失误 |
 | 19 Qcchen 2024-08-30 11:51:14 +08:00 设计纵向表不能满足吗? 听这个需求就和低代码平台的动态配置表单一样。 |
 | 20 rookie8 2024-08-30 16:52:15 +08:00 可以试一试非关系型数据库，比如 MongDb ，增加字段不用改表结构，而且学习成本极低。 使用 MongoDB 来实现对自定义表（没有预定义实体）的通用增删改查操作，要得益于 MongoDB 的文档存储模型和灵活的架构设计。以下是一些关键原因和解释： ### 1. **文档存储模型** - **JSON/BSON 格式**：MongoDB 使用 BSON （类似于 JSON ）格式来存储数据。这意味着数据是以键值对的形式存储的，每个文档（类似于关系型数据库中的一行）可以有不同的字段、数据类型和结构。因此，你不需要预定义特定的表结构或实体类，这使得操作动态集合（即自定义表）变得非常方便。 ### 2. **灵活的 Schema** - **Schema-less 设计**：MongoDB 的一个重要特性是它的 Schema-less 设计。不同于传统的关系型数据库，MongoDB 不要求所有文档在集合中具有相同的结构。这种灵活性允许在同一个集合中存储结构不同的文档，并且你可以根据需要动态地添加或修改字段，而无需修改数据库的整体结构。这就使得对自定义表的增删改查操作变得更加灵活，因为你不必事先定义实体。 ### 3. **MongoTemplate 的灵活性** - **操作任意集合**：在 Spring Boot 中，`MongoTemplate`提供了直接操作 MongoDB 集合的方法，它不依赖于实体类。因此，你可以通过集合名称（相当于表名）和文档数据直接对集合进行增删改查操作，而无需依赖于特定的 Java 实体类。这使得处理动态集合变得非常简单，尤其是在处理结构多变的数据时。 ### 4. **动态字段支持** - **嵌套文档和数组**：MongoDB 支持嵌套文档和数组，可以在一个文档中存储复杂的数据结构。这种灵活性允许在不改变集合结构的情况下，轻松存储和查询复杂的数据。这在动态数据模型中尤其有用，因为你可以在不同的文档中存储不同类型的数据。 ### 5. **查询语言的灵活性** - **动态查询**：MongoDB 的查询语言允许构建动态查询，你可以根据条件灵活地检索、更新或删除数据。结合`MongoTemplate`，你可以轻松地构建动态查询条件，而不受限于固定的表结构或预定义的实体类。 ### 6. **不需要预定义数据库结构** - **无需迁移或重构**：在传统的关系型数据库中，添加新字段或修改表结构通常需要迁移或重构数据库，而在 MongoDB 中，由于其灵活的 Schema-less 设计，你可以在应用程序中直接操作和存储数据，而无需事先定义数据库结构。这大大简化了对动态数据的处理，特别是在快速开发和迭代的场景中。 ### 7. **高效的性能和扩展性** - **水平扩展**：MongoDB 原生支持水平扩展，这意味着即使在处理大量动态数据时，性能和可扩展性依然可以得到保障。这使得对自定义表进行增删改查操作的同时，能够保持较高的性能水平。 ### 8. **适合多变和非结构化数据** - **应对多变的数据需求**：在实际应用中，数据需求可能经常发生变化，MongoDB 的灵活性非常适合这种情况。它允许开发者快速响应变化而无需对数据库进行复杂的更改。 总结来说，MongoDB 的文档存储模型、Schema-less 设计、以及 Spring Boot 中 MongoTemplate 的灵活性，使得它能够轻松处理自定义表的通用增删改查操作，而不需要预定义实体。这些特性使得 MongoDB 在处理动态、非结构化或半结构化数据时具有很大的优势。 |
 | 21 littlepigpeppa 2024-08-30 17:24:09 +08:00 1 我之前也有你这想法，去年还实现了一个版本，数据库表运行时动态管理、自定义字段校验规则，自定义表单、自定义数据表、自定义接口、提供通用的 CRUD 接口（包含自动联表），支持运行时自定义脚本载入等等 |
Select Language