Base solution for your next web application
Open Closed

Tenant ID in every Entity? #1664


User avatar
0
joe704la created

I am very new to Multi-Tenant applications.

I have some Entities that I inherit from the User class. So, for example, a Renter inherits from User and a Landlord inherits from a user. Then I have some Entities that map to tables that are a one to many relationships between the Renter and also the Landlord such as LandlordDemographics. Should classes like LandlordDemographics implement the IMayHaveTenant interface and have the TenantId Foreign key in it? So basically should all classes have the Tenant Id in them when developing a Multi-Tenant application? or should only the main class such as the User class have it?


2 Answer(s)
  • User Avatar
    0
    hikalkan created
    Support Team

    Well.. this topic can be discussable and it's a design preference. But I will explain my idea briefly.

    1. In general, do not add foreign key for any TenantId property, if you ever want to store tenant data in a seperated database (like db per tenant approach). In that case, Foreign key can not work since the entitiy in a different db than the Tenants table.

    2. You can add TenantId only to aggregates (like User) which you directly query. But in practice (in relational databases) you may need to directly query child entities. So, I suggest you to add TenantId to all tenant-related tables.

    3. As you probably know, there are two interfaces: IMayHaveTenant and IMustHaveTenant. If a LandlordDemographics entity can be belong to only a tenant (but not host), you can make it IMustHaveTenant for a better data representation and relation.

  • User Avatar
    0
    joe704la created

    I don't fully understand your first point to not add foreign key TenantId property because then it sounds like I should for point 2 and 3. I think the reason it doesn't. make much sense is because I never understood the benefits of having the tenant data in separate databases. That is for sure over my head as Multi-tenancy is so new to me.

    2 and 3 make perfect sense to me. 3 fits my scenario the best. I am going to switch to IMustHaveTenant.

    The reason is as we are in Alpha testing and through Beta testing, this app is actually going to be more of a single tenant app and Multi-tenancy will be turned off. But I want to design the system to support Multi-tenancy so in the future once we have ironed out all the bugs and quirks of the system we will be opening it up to multi-tenancy. So I have to be careful how I design it.