Base solution for your next web application
Open Closed

Multi Tenant - Multi DB Approach Questions #4085


User avatar
0
slapointe created

Hello!

Would it be possible to set up ABPZero to only keep Abp related tables on the HOST DB and only add business logic/tables to the tenant DBs, I noticed when creating a tenant it will create all the Abp Supported tables under the new connection string.

If not, could you expand on the reasoning behind this?


1 Answer(s)
  • User Avatar
    0
    alirizaadiyahsi created

    First, from this document:

    Single Deployment - Multiple Database ln this approach, we may run a single instance of the application in a server. We have a master (host) database to store tenant metadata (like tenant name and subdomain) and a seperated database for each tenant. Once we identify the current tenant (for example; from subdomain or from a user login form), then we can switch to that tenant's database to perform operations.

    In this approach, application should be designed as multi-tenant in some level. But most of the application can remain independed from multi-tenancy.

    <ins>We should create and maintain a seperated database for each tenant, this includes database migrations. If we have many customers with dedicated databases, it may take long time to migrate database schema in an application update. Since we have seperated database for a tenant, we can backup it's database seperately from other tenants. Also, we can move the tenant database to a stronger server if that tenant needs it.</ins>

    And tenant isolation : The developer needs to ensure that no tenant has unwanted access to other tenants’ data. The isolation requirement extends to other properties, such as providing protection from noisy neighbors, being able to restore a tenant’s data, and implementing tenant-specific customizations. ([url=https://docs.microsoft.com/en-us/azure/sql-database/sql-database-design-patterns-multi-tenancy-saas-applications]Source[/

    In light of this information What are the ABP tables: Backgroundjobs, editions, users, permissions, roles, ... These are tenant specific tables, so you should not keep data that are related these tables in a shared connection string.