这不是我想的工程。不适合在 V 站讨论。

@sdrzlyz #49
如果你能就你的观点展开讨论那就有说服力了，最好是有对比数据甚至实际案例。

@tomjames #50
直接问他们就像：Hi ，竞争对手，我想问问你们怎么设计的以及有哪些困难，最好顺便说下 RoadMap ，我们好参考一下。[doge]

@hyacinthus #45
其实也看场景，对于企业级应用，如果有几万正式租户可能就发财了。

@AyaseEri #46
嗯，MongoDB 是低代码平台主流 DB 。我们目前的定位还是想做企业级包括可能允许深度二次开发，需要传统的关系型数据库而且后期需要支持常见关系型数据库。总不能强迫客户使用 MySql 吧，让客户在企业经营环境使用 MongoDB 也不太妥。

@lecher #47
让租户回归到自己的数据库是核心，这种模式的产品很多，比如 ES 官方的服务就是这么干的，Snowflake 也是。

@lecher #42
感谢，你上面给的方案已经很详细了。

其中根据 TenantId 做路由我倒是有想，但把 MySql 实例也用类似方式表达有点担心连接资源是不是会占用太多？我想的是加在数据库实例名称中，比如 ABC_TenantId 这样，一般租户共用数据库连接资源，特殊租户有独立的数据库实例，在同样是在应用入口做转发。

同时部署两个版本也是我没设想的，我设想的是升级的时候两套逻辑同时支持，然后在下个版本中移除。

@wonderfulcxm 异性就没那么尴尬了

@3dwelcome
我之前搞新系统为了高性能直接上 NoSql ，步子迈太大结果差点蹦了，现在对于新项目，没有足够的理由我也是不太想换数据库。

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

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

那还有啥意思？

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

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

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

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

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