多数据库 同步字段的问题

典型的多租户模式。

如果用户量比较大，还是 tenant_id 模式比较灵活，这样可以一户一库，也可以多户一库，可自由配置。缺点就是程序改动比较大，另外就是数据安全性。

@Hellert #1 各有优缺点吧；目前主流的 3 种，目前使用的第二种。

独立数据库：每个租户一个数据库。

优点：为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求；如果 出现故障，恢复数据比较简单。
缺点： 增多了数据库的安装数量，随之带来维护成本和购置成本的增加


共享数据库、独立 Schema：即多个或所有的租户使用同一个数据库服务（如常见的 ORACLE 或 MYSQL 数据库）， 但是每个租户一个 Schema 。

优点： 为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可支持更多 的租户数量。
缺点： 如果出现故障，数据恢复比较困难，因为恢复数据库将牵涉到其他租户的数据； 如果需要跨租户统计 数据，存在一定困难。

共享数据库、共享数据表：即租户共享同一个 Database，同一套数据库表（所有租户的数据都存放在一个数据库 的同一套表中）。在表中增加租户 ID 等租户标志字段，表明该记录是属于哪个租户的。

优点：所有租户使用同一套数据库，所以成本低廉。
缺点：隔离级别低，安全性低，需要在设计开发时加大对安全的开发量，数据备份和恢复困难。

你们业务经常加字段的，惊！ dba 是干什么去了！再惊！一般扩展字段是 mediumblob, 这个是 protobuf，你要加几千个字段都不用改数据库

惊！
一挂全挂吗？

@123444a #3 版本升级咯

@adminisqq
"将来会上千个、上万个库"，如果真是这样，趁早改成支持多户一库

1 、完全一个租户一个数据库的模式，可能是一个坑，建议支持多个租户一个库的模式；
2 、各个产品加字段的问题，需要考虑，是不是每个库 Schema 都一致，如果一致，各个产品对于数据库的结构变更，需要串行化，并行会有各种坑，找 DBA 写个工具，同时将新脚本发布到各个库上执行，不是太难；如果 Schema 不完全一致，对于开发来说，就是个巨坑，可以考虑使用列式数据库，如 Cassandra ；

1 多用户 1 库
2 字段整合

如果业务很稳定，每个用户都是使用相同的业务，那么建议多用户使用 1 个库
如果业务不稳定，用户和用户之间的业务模型有明显区别，那么库必须分开，此时应开发专门工具来同步字段并检查同步效果