Sharding: Move Tenant to database

There is only one extra Tenant Admin command when you are using many-databases structure (e.g. when the TenantType property in the AuthP options has the AddSharding member added) is the MoveToDifferentDatabaseAsync. This method does two things:

• It can move the tenant's data to another database, defined by the connection string names.
• It can change the tenant's HasOwnDb property, which will change whether the tenant has its own database or not. Note the you can just changed the HasOwnDb property, then it changes the database arrangement.

This means you can:

• A tenant in a shared database (i.e. many tenants in one database) can be moved into a database that is only by this tenant (known as a shard) for better performance / security, but more cost for the extra database.
• A tenant in its own database (sharding) can be moved into a shared database with other tenants in the same database. This is cheaper, but the individual performance / security of the moved tenant is slower.

NOTE: In Azure's SQL Server elastic pool this is known as split-merge.

The MoveToDifferentDatabaseAsync method is easy to use, but be aware implementing the code your tenant change service is quite difficult to write. See the MoveToDifferentDatabaseAsync implementation in the ShardingTenantChangeService, which is a simple move. Real databases would need much more work to create the code to move a tenant in a shared database (i.e. many tenants in a single database) into its own database, or visa-versa.