Where to place registration logic for multi-tenanted database design?

Question

I am currently in the process of turning a single-tenanted application into a multi-tenanted application.

As far as the database design goes, I have chosen the 'Shared Database, Separate Schema' solution as described within this article.

Following the instruction provided; I am required to perform the following steps, each and every time a new tenant is introduced:

1. Create new Schema for tenant.
2. Create new database user with access to the newly created schema(and only this schema).
3. Create necessary tables within the newly created schema.

My question is, where should this logic be placed?

My initial thought was within a stored procedure, however I am unsure of this decision and looking for some clarification.

Answer 1

I would like you to look into this implementation from a deployment perspective too.

Considering the fact that executing a job in Sql would be faster or even raising a tenant created event which can run a job that will be creating the necessary db infrastructure. At the end, the job will call a rest end point your app that can activate the tenant, so that the tenant can get into the app and use.

There are many options to be considered in the approach because it will be fully distributed and prone to failures.