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

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

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

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

@jack778
Schema 可能还不如用多个数据库。我设计过的 SaaS 平台都是共用数据库和表，通过 TenantId 区分的，前提是这些客户功能和表结构差不多。但低代码完全不同，每家表结构都可能完全不一样。

@forgottencoast
嗯，我已经不是新手，我十年前就开始设计 SaaS 了。那些系统我也是用租户 Id 隔离的。

@xuanbg
嗯，我很同意你说的。其他系统我也是这么设计的，只是低代码太动态了，共享表显得没意义。

@lmshl
低代码的问题是所有数据都是动态的导致它几乎没共享可言，这是跟传统 SaaS 的最大区别。普通系统你还可以建立多张表来维护，到低代码直接一个通用表，二维都压成一维了，当然你硬创建一个 4000 字段的表做元数据也不是不可以，或者说使用 Json 更为简单，但又得考虑性能和稳定性，以及现有开发人员是否足够熟悉。在我看来用 Schema 可能还不如用多库，而外键因为我们选择不在数据库设置外键也没什么影响（这个话题可以展开之前也有人讨论过，我们不在 DB 设置是因为性能和易扩展比如分表分库，在我们这边对 DB 的定位就是只负责存储数据和索引，不要做过多校验和计算）。

@documentzhangx66
你说的很有道理，Oracle 买不起也没用过，在我们这边看来 MySql8 哪怕用 Json 存储都可以撑得住的。

好像谷歌地图不是，我一直用它导航

@lmshl
因为低代码的场景太动态化了，再加上对 PostgreSql 不太熟悉，不确定它能不能基于 Schema 做备份和还原。目前方案是每个租户独立的 MySql 数据库，动态创建表格。这样也方便备份和独立部署。可能升级会麻烦些。

@westoy
那就是 MySql 啦，我现在初步定了 MySql+每个租户独立数据库的方案。

@cpstar
客户完全动态定义表单列表啥的，如果共用数据库那就得用 Json ，这样最简单直接，如果独立数据库，就可以不用 Json ，这样有啥问题么？而且因为是低代码，提供的业务也是动态的由客户建立起来的，即使独立数据库有些场景还是需要用 Json 存储的，具体产品可参照简道云。

@XiLingHost
ES 不是 DB ，我最多拿它来做搜索。MongoDB 得一票。:-)

@lecher
我也考虑过这种方案，但总感觉代价太大，想想如果有上万个租户，不确认数据库连接是否能跨库，也可能会导致升级变得麻烦。好处是性能会好很多。

op 你忘了润

本质上是因为你有精力了，干体力活让能的大脑放松下来了。我不怎么运动，但凡我活不多甚至摸鱼多的时候，sex 生活就特别强。

之前我是倾向于使用轻量级 ORM 就像你说的 Dapper （实际上我用的是 NPoco ），但现在我倾向于使用 EF 。手写 Sql 非常不利于重构。

@ch2
这问题不大，都本地程序了。基本上都可以让 JS 与程序本身互调用的，基于此就可以让他们通讯。再不济你程序架一个本地 HTTP 让他们互通。

@fstar 我在国外我们的屎山项目也不写，我们一样在重构，还一堆存储过程，工资不错，慢慢整呗，整好了就是人物。

一台电脑不够用<=>性能是够的。
像楼上说的加显示器吧。

我是小部分人，我用 Outlook 。

这种情况你把它加入到例外就是了。

操作系统已经压过舔狗和润了

家人之间也要防诈骗，先定为垃圾显得谨慎[doge]。

@whusnoopy
天色已晚矣。。。