2

I am having thoughts on what design should I take on my current application architecture. I am building multiple sites (different products) then requesting to a centralized API for data.

My initial thoughts of the API database would be:

common_db

  • This database likely contains common entities such as user (id, details, etc.)

first_site_db

  • This database contains table with data specific for the product site

second_site_db

  • This database contains table with data specific for the product site

... and so on.

Is this a bad database design practice? Considering this is fine, what particular technique should I implement in order for each product database to get the user details on the common database?

1 Answer 1

1

It is not a bad design at all, and it is not something new.

In MySQL any operation involving multiple tables can also involve multiple databases, so you won't have functional limitations.

The drawback is the complexity that you will need to add if you need to shard the databases across multiple servers/clusters. Because you will need a way to replicate the common_db, and nothing else, to all servers. But, even if you choice another model, you will hardly have an easy solution for this problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.