Question

I have a multi-tenant MySQL database. For most things I use a tenant-id column in tables to discriminate but for a few purposes, it is much better to have a view that is already filtered by tenant id. So for example, I might have a view called ‘quarterly_sales_view’ but for tenant 30 I would have ‘quarterly_sales_view_30’ and for tenant 51 I would have ‘quarterly_sales_view_51’. I create these views dynamically and everything is working great but we have just a few tenants right now and I realize this would never work for millions of tenants.

My question is, am I going to run into either performance problems or just hard limits with a few thousand, few hundred, or few dozen custom views?

ADDITIONAL INFO:

I am using a 3rd party tool (immature) that requires a table name (or view name, since it’s read-only) and operates on that. In the context it’s working, I can’t let it have access to the entire view, so I create another view that is simply defined as SELECT * FROM MasterView WHERE TenantId = 30. I recognize this as a workaround for a poor limitation of having to have the tool work on the table directly. Luckily this tool is open source, so I can tweak it to use a different approach. I just wanted to have an idea of how long I had before the current approach blew up.

Answer 1

The primary concern within this question (IMO) should be less with performance and more with the design. First, the number of views should not affect performance, but, why do you need a view per tenant? Is it not possible to simply filter for a tenant by ID on a more generic view. E.g.:

SELECT * FROM vwMyTentants WHERE TenantId = 30

Whatever the reason, you should reconsider your approach because it is a sign of design smell.