5
传统实现方案及问题
如何以一套统一的数据架构即能支撑多租户的数据安全性需求以及通用的数据存储，也能支撑用户扩展的自定义
数据对象定义和模型变更，同时也要保证数据定义层面的扩展和变更不会影响自身和其他租户的业务功能的可用性。
一、统一的数据库，标准数据模型和扩展数据模型直接映射到物理表和索引：很显然对于不同的租户自定义的数
据对象和数据模型要求是无法支撑的，物理数据模型会相互干扰，相互冲突直到无以为继。即使是对于所有租户
完全标准的功能和数据存储，平台自身的标准模型的升级的 DDL 也会对用户的可用性造成较大影响，所以显然是
行不通的。
二、如果为每个租户创建各自的数据库呢？各自租户拥有各自的数据库，可以满足用户数据安全隔离的需求，也
可以满足各租户自定义的数据需求，看上去像是一种合理的 SAAS 数据方案，但是仔细分析，发现有几个明显的
问题
1 可用性：如果用户需要修改或者扩展现有物理数据模型而进行的 DDL 操作，必然会影响线上业务的整体可
用性，也可能会影响到标准数据模型，从而影响到线上功能使用。
2 扩展性：如果用户可自定义对物理模型进行扩展和定制，当平台进行模型升级的时候，极容易产生物理模
型的冲突，导致新旧功能异常。
3 安全性：由于用户在各自数据库存在各自定义的扩展和定制，则平台数据模型和功能升级，需要针对不同
的租户进行分别验证，存在着极大的升级验证工作量和风险。
4 复用性：开发的相同功能想要服用到不同的租户上，需要业务代码，数据库进行人工复制效率不高。
