How to work with multi tenancy architecture?

I recently worked on a multi-tenant project. I did not participate in the architecture decision; I just did maintenance and development with the project at an advanced stage.

There was a "central" database, which even had the tenants' registry itself. And, for each tenant, among the procedures at the time of its inclusion, a new database was created.

The architecture seemed very good to me, and the code was also well-structured, well-coherent, without confusion. From this brief interaction with this system, I would not recommend using the same database for all clients. Separating "one database for each client" makes all application development much simpler.

Each case is a case, but the suggestion comes from contacting a real application: a "central" DB and a DB for each client is a good request.

P.S. Of course the tools you have and your experience with them will be important in managing that complexity. In this case, the application was in Symfony 2 (which I particularly do not like ), but I imagine the same architecture as Laravel 4 particularly taste ) without much difficulty.

Use the same database for all clients or build a new database for each new client?

What to look for:

1 - How many potential users do you expect to reach?

It is complicated to estimate quantity with authority, but I think  which in terms of orders of magnitude would be: Thousands? tens of thousands? more?  If it is a high user size it would be advisable to use the shared approach.

2 - How much storage space do you expect from average user data to occupy?

If you expect that these users will have to store large amounts of data the separate database approach is probably the best.

3 - How many concurrent users do you expect to support?

The higher the number, the more appropriate isolation would be to meet the requirements.

4 - Do you expect to offer any per-tenant value-added services such as per-tenant backup and restore backup?

Such services are easier to offer through a more secluded approach.

Of course, with the growth of some technologies the support / storage of information can easily be questioned, but in short, this is!

Analyzing your problem:

The application will cater to companies (salons) that may only have

  

the headquarters unit and / or the headquarters unit and the branch units. All the   two types will be multi-users and several modules, some being:   Customer registration, Supplier registration, Registration of   professionals, Product and Service Registration, Agenda, Control of   Stock, Financial, Sales and Purchasing.

If you understand all that I have explained above your doubts will be as follows:

Companies will ask for additional service as backup or have several other features that do not make sense to have in another salon (Relative to companies that sell a Service and customizations for each client.)?

Then it will be recommended to isolate the database, otherwise prefer to use a shared database.

Reference: How to create a multi -tenant database with shared table structures?

Separate benches give you more security. However, it is easier to implement an approach using the same bank. If you can, go from separate benches.