Reputation: 1664
I'd like to solicit advice on how to design the database(s) for a suite consisting of multiple products.
We have implemented a multi-tenant cloud-based product using MySQL, under a brand that we own.
Now, we'd like to add a new product under the same brand. Once it's done, our customers would be able to choose to use both products based on their plans. These two products are related but largely independent. A customer can subscribe to use any of them only, but together, the two products have some synergy by interacting with each other.
In the future, we plan to add more products to the suite to enhance the UX and value.
From the customers' perspective, they only need to create a single account with us, then they are free to choose from any combination of our offerings.
A real world example is Office 365: you need only one account to use their various products like Word, Excel, etc.
Below is what I think is possible for such a scenario.
Create multiple databases, with each one for each product. For example, create a database db1 for product 1, and db2 for product 2.
When the user uses product 1, db1 is queried for the data. Same for product 2. If he uses both, both db1 and db2 are queried.
As for tenant/user/credentials management, create a separate database meta with tenant/user tables in it. When a user logs in, the meta db is queried.
We are using MySQL here, but I assume the core design should be largely independent of the actual DB software.
Upvotes: 0
Views: 39
Reputation: 333
I think you are on the right path.
"These two products are related but largely independent". I'm understanding from this comment that the products don't have enough in common to share logic. So two databases sounds like a good choice to keep the data clean.
You can have shared databases for order info, user info, reporting, and maybe application metadata that is cross-product.
Upvotes: 1