When you have a single application and several different clients, it can be advantageous to have a single database serving everyone (as you claim to be the case with Wordpress and Joomla). This does not come without challenges, however - see my answer to that related question for a real example of how this can be done, and the care that needs to be taken for one client’s data not to mix with another’s data. That article about multi-tenancy cites other possible strategies, such as using the same application but different banks, or even separate instances of the application for each client (strategy I myself used in a recent project).
Whether it is advantageous to maintain a single bank for all customers, whether from a performance or maintenance standpoint, is debatable. Personally, I believe that a single bank brings more agility to register and unsubscribe customers (just enter/delete records from a table instead of creating/destroying entire banks), while multiple banks make it simple to do backups (no need to worry about data from one customer going to the backups of another) and maybe simplify scale growth (you can scale single-seat systems as well - through "vertical" or "horizontal" partitioning - but I don’t have enough practical experience to comment).
In your case, however, the fact that customers - and the application that will serve them - are substantially different from each other is practically the decisive argument for choosing to have separate banks; a complicating factor in architecture multi-tenant is just like customizing a customer’s experience without "breaking" the system for everyone else (if the customer wants an extra field in table X, you can’t just put it, otherwise everyone else would also have to receive that field). And in this case the factor is present from the beginning, because you know that will need different data structures (and code)...
As for one client needing to reference the other in their database, I would say not to worry too much about this: first of all because this case is not foreseen, it is only a speculation "what if?" , and as far as I know this is not a common scenario at all; secondly, because even if it eventually comes down to it, the lack of referential integrity (i.e. not being able to create foreign keys from one bank to another, with guaranteed integrity) should not be such a problem that it cannot be dealt with in its application layer.
Related. There are advantages and disadvantages of using different banks for different customers, but as in your case, application in itself is sufficiently distinct from one client to another, I would say that separate banks is the most recommended way. Although they have some similar tables (but not shared), it is better to repeat them in one and the other bank, sharing only the software modules that create and manage these tables.
– mgibsonbr
Would the performance be better? taking into account that the two banks are on the same server. The problem would be future had to implement a related table between the two... This has no way to do right?
– felipe.rce
I’m not sure the performance difference would be significant. The fact that the SGBD is the same softens things up - if it were two different Sgbds, then they would "fight" for the features of the machine... As for a table relating the two, only in the same bank. If you need referential integrity, of course. But I have a hard time imagining a scenario where the data of two different clients needs to be related; they’re really different clients, or just users distinct from the same client? (type, two departments in the same company).
– mgibsonbr
are distinct customers who use the same system, for example in the ifood app has the customer who wants to buy food and the customer who wants to advertise, they use different apps and have similar but different registrations, my app follows this model, with another objective. Also I can’t imagine a scenario that this might occur, maybe it doesn’t happen or maybe it does. I’ve also never seen someone do it like this. But I think I’ll separate the banks, get more organized, and it’s better when it comes to backing up
– felipe.rce
@mgibsonbr creates an answer to the content
– felipe.rce