多租户低代码平台数据库选择问题

赞同
方案 4. 独立数据库+每个表单一个表（创建字段）

方便后期分离和优化，比如 saas 中其中有个用户用户量非常大、并发非常高，需要独立部署和高配置，就很好解决；

Oracle 为什么强？
我记得 10 年前，线上业务 bug ，有死循环直接访问数据库，1 个小时访问了几亿次数据，Oracle 报警了，但对其他业务没有任何影响

@blackboom
多谢提供分析和建议。

我这边是最终都不一定会采用 Json 的方案，如果使用方案 4 即动态创建表和字段，则 Json 性能差一些也没什么影响了。MongoDB 一是不熟悉二是对 Sql 及统计的支持很有限，我们同时也在考虑允许客户二次开发，这种情况下使用常见的数据库更为重要，所以还是聚焦在关系型 DB 上比较好。

回到 PostgreSql 上，同样我们也是不熟悉，这就会带来额外的工作量以及不确定的风险，二是国内各云商对 MySql 支持得比较多也优化得比较多，我个人在阿里云买的 1C1G 的跑了 N 多系统有的数据量还很大它还是很强，而且有开箱即用的慢 Sql 和恢复到任意时间以及只读实例等功能。这样下来的结果就是除非 MySql 的 Json 比 PostgreSql 慢一个数量级我们才有可能考虑。何况要不要用 Json 我们还没最终拍板，很有可能只用它来保存表单配置以及涉及到工作流的部分。

@xzysaber
ES 我只会用它来做搜索哈，不会真正拿它当 DB 用。我在电商系统里用它来搜索商品，偶尔还遇到全部丢失无法查询需要全刷一遍的问题，这种如果发生在 DB 里是会挨揍的[doge]。

postgresql 很适合企业应用

复杂查询(自子查询,表链接)等场景, 性能表现远超 mysql, 当前有测试我们自身的业务表现

至于 mysql 的确当前选择的很多, 但看看他们的一些要求

* 不用外键
* 不用表链接 等等

就知道对于企业应用软件场景根本就不适合

简单的如进销存 erp 软件,每报表必须有合计和小计, 查询条件多且多遍, 直接把一些互联网应用投机取巧的优化给打回去

不得不老老实实的依赖数据库本身的表现

低代码的 json 需要检索吗？不然不就是 string 吗？

@jjx
目前很多低代码平台还在用 MongoDB 呢，关联查询更是要命更别说报表了。

目前来说都是关系型数据库，真遇到问题或瓶颈，迁移起来也容易些。像报表这种，前期直接查，再慢就提前准备数据，再不行就把数据同步到 BI 平台，让专业的人去做专业的事情可能更好。

另外求助，有哪里可以看到详细地对比么，尤其是实测？我查了一些不是很全，我自己的体验是电商数据库从 Sql Server 切换到 MySql ，性能也没有明显变化。

@joesonw 不止检索还有可能要分析统计。

复杂的 json 检索还是放 MongoDB 好一点。统计分析这些不想用 MongoDB ，可以 ETL 倒入到适合分析的数据库嘛，没必要强行放一块。

@cpstar manggo 不是单纯的 kv

@Chad0000
关于 pg 的跨租户外键和事务，我的态度是：“我可以不用，你不能没有”
确实你“物料库”里的数据是无需事务与外键的，但你的物料创建关系，以及用户，资产还是免不了需要事务机制。
我司从去年也在把现在的 SaaS 多租户平台往低代码上升级，实际上我们做的事是很高度相似的，元数据管理，用户自定义动态字段，规则引擎等等

很难理解为什么同一个人会针对同一个场景既提倡 Oracle 又以提倡 MySQL 为保底反对 PostgreSQL…论起能力来 O 和 P 的相似性很高，M 几乎都不是一个物种。

@adoal 可能因为 pg 是新鲜事物吧。。。

低代码 mongo 你是坑死个人，现在的低代码都有自动建模功能

肯定要用 mysql

1.是大家都熟悉，技术门槛低
2.不要选文档数据库，传统数据库有 scheme 约束，对代码质量，可维护性都是一个保障


这事不好解决，没有完美方法，我做的 saas ，最开始也是用一个租户字段进行区分，行级别隔离，后面市场规模扩大，有些大客户要求独占，又开始来拆分，几乎要全部重构


但是一开始就搞一个租户一个 db ，也是很难决策的，因为成本很高，没有人能保证项目一定能成功

postgresql + schema 隔离 +1

@blackboom

1.因为 Oracle 是地球上最强的数据库，而且还不止数据库。


2.你可能不了解 MongoDB 的黑历史，建议去了解一下。比如丢数据的黑历史。


3.建议先去了解一下这两款数据库的历史，关键字：Release history 。你在这方面有知识盲区。


4.MySQL 和 MongoDB 可能没有 PostgreSQL 好？？？？

虽然在我眼里，Mysql 、MongoDB 、PostgreSQL 都是垃圾，但这 3 个垃圾相互比较：

Mysql 在被收购前后，都很努力。至少没有出现过，像 PostgreSQL 作者那样耍无知，觉得内存表完全不需要，由 OS 去管理就好的傻子言论。还记得比尔盖茨曾经说，多少 KB 的内存就能满足人类使用嘛？

MongoDB ，你去翻它的黑历史，以奸商的出发点去做数据库，能做的好？只是那阵子被大佬扒光了，近几年稍微收敛了一点。但从商业模式来看，后面肯定还会作妖。ps.这结论不是我看出来的，是某商业大佬带团做背调后发现的。

PostgreSQL ，我根本不想评价。前几天有个 .Net 团队大佬，打算从 Mysql 换 PostgreSQL ，对它做可行性分析。我一开始就告诉他，别浪费时间，他不信。调研了一周后，他也郁闷了，而且某些关系型数据库的核心功能，居然至今还是缺失。


5.另外你提 json ，我是建议楼主，先试试中间件。其他主流 ORM 如果楼主不会用，我建议他试试 FreeSQL 也行。FreeSQL 的作者，无论技术实力，还是对大家提问的热情度，让我觉得 FreeSQL 能够高质量地稳定发展下去。


6.多租户，只是一种业务模式，与用什么数据库有啥关系。这问题好比是：是否只有 Java 才有 OO ，汇编与 C 就没 OO ？

@Chad0000

买不起没关系，白嫖就完事了。让 Oracle 在纯内网环境下跑，不让它访问外网。

想要稳一点，找个第三方 Oracle 运维公司，花点小钱，让他们帮你们做做架构，买个自动化运维脚本，再送你们最新补丁。

@Chad0000
跨库的业务操作应该显式写集成业务，这种集成业务是隐藏不掉的，应该让这类的业务归纳入版本管理中，至于跨租户的数据集成问题，可以考虑引入其它 OLTP 数据库来支持集成。

升级的问题同理，变更是很难通过自适应的业务流程计算出 diff 并升级的，应该让开发讲升级 /降级的变更写成迁移脚本，归纳入版本管理中随代码迭代。
升级无法进行版本管理并自动化，会让新业务的上线变得更加困难，需要支持按租户区分功能开关的形式，业务代码可以随时灰度上线。隔离好变更的影响范围。

投 mysql 一票，没别的原因，就是国内用的人最多最火。

如果是我写低代码平台，应该会用 leveldb 之类的 kv 数据库，但是不推荐大家用。一是查询需要全部自己建索引额外处理，二是 nosql 也是需要实际经验的，没经验还不如用 mysql 实在。

@documentzhangx66 #37
Oracle 同样我们也不熟悉哈，像这种新产品如果熟悉的 DB 能搞定性能没太大影响的话，肯定是先用熟悉的来，所以是 MySql 了。FreeSql 我会去看看，之前就 Star 他们了。

@lecher #38
你的思路是对的，而且之前我们的 SaaS 平台是先更新表（没有 Not Null 约束），再更新系统。而你的按租户设定开关，则会让升级变得更平滑，更适合这种无法短时完成升级的平台。而且私有化部署的升级也需要我们准备这些。