在设计系统时 对高级用户和普通用户进行区分 普通用户共享一个数据库通过一个标示来区分数据 高级用户有自己另一套数据库 基本的表结构类似 但这些高级/普通用户基本信息都统一由超级管理员进行管理 这种设计方式会不会有问题 如果可以实行 那么如果是高级用户登陆系统(高级用户的数据库地址存储在基本信息中) 那么登陆在系统时怎么切换连接到高级用户自己的数据库 官网说可以通过_unitOfWorkManager.Current.SetTenantId() 达到这种需求 但是测试只是通过标示区分了实体数据 并没有切换到另一个数据库
类似于下图这种结构 通过存储的节点 来切换数据库
ABP的框架是多租户概念,没有分多个数据库的概率,其实是每个表都会多出一个TenantId的字段,再结合EF的EntityFramework.DynamicFilters,在你每次查询的时候来过滤数据
多部署 - 多数据库
这种实际上不算多租户,但是,如果我们为每个客户(租户)运行应用的一个实例,并使用一个独立的数据库,那么我们就可以在一台服务器上为多个租户服务,我们只要确保应用的多个实例不要在一个服务器的环境下互相冲突就行。
为一个不是为多租户设计,但已经在运行的应用,提供了可能性。这种方式虽然使得创建一个不考虑多租户的应用相对容易,但在安装、使用和维护方面有些问题。
用这种方式,我们在一个服务器上运行应用的单一实例,我们有一个主(宿主)数据库存储租户元数据(像租户名和子域),并为每个租户维护一个隔离的数据库。我们一旦识别当前租户(例如:从子域或从一个用户登录窗体),就切换到该租户的数据库里执行操作。
用这种方式,我们应该在设计应用时,在某些层面上设计成多租户,但应用的大部分还是不依赖于多租户。
我们应该为每个租户创建并维护一个隔离的数据库,包括数据迁移。如果我们有多租户就需要维护它们专有的数据库,在应用更新时,可能就需要花很长的时间进行数据库结构迁移。由于我们有租户的隔离的数据库,所以我们可以单独地备份各自的数据库,同样在租户要求下,我们也可以移动租户数据库到一个更强大的服务器。
这是最纯粹的多租户架构:我们只在一台服务器上部署应用的单个实例和单个数据库。我们在每个表(关系型数据库)里用一个TenantId(租户Id或类似的)字段来区分隔离每个租户数据。
这种方式易于安装和维护,但难于创建这种应用,因为我们必须防止一个租户读或写其它租户数据。我们得为每次的数据库读取(select)操作添加TenantId来过滤。同样,我们也在每次写数据库时进行检查当前实体是否与当前租户相关,这就是乏味和易犯错的地方。但ABP自动使用数据过滤技术帮我们解决这些问题。
这种方式在有很多租户和大数据量的情况下,可能带来性能问题,我们可以使用表分区或其它数据库特性来解决这个问题。
我们可能想存储租户数据到一个数据库,但想为有需要的租户创建单独的数据库。例如,我们可以存储租户的大数据到各自的数据库,但其它的都保存到另一数据库。
最后,我们可能想部署我们的应用到多个服务器(像分布式服务器集群)获得更好地性能、实用性和扩展性。这是一种依赖于数据库的方式。
文档介绍上面说的 ...如果要这样说 错了三四年了......我的天。。
ABP封装好的SetTenantId在租户与宿主之间切换 并且开启过滤不影响其他租户数据的使用