You are most welcome.

Thank you I’ll take a look.

John

Well maybe it could, but in the case you described, the client is working with a single database it is just matter of which db you assign to that client once they are logged in. We have an article on multitenant applications, just search for it in the search input field. Maybe that one can help you even more.

thank you

Well, without going too much into why you have this db structure, and why this is not just a single table, I must say that I don’t understand why you have master and slave DBs where you just read data from one db and modify data in another db. When you do update, you have to read the data, assign changes, and then execute the modification in db, for me, it just doesn’t make sense to have two DBs. That means, if you delete the data from the master table, you should do it in the child because both have the same data… This is just redundant. I never worked with such a db structure and to be honest, I have no idea what is the proper way of handling that.

thank you, but when I read data from slave/readonly (for example table x and record with id 5) database and than for some reason I want to update this record, (update must happened in master) how can I handle this? I must read record again from master(table x with id 5) and than update?(probably no )

Well, we don’t have anything that specific. But, since your repository user classes (in this article CompanyRepository and ClientRepository) communicate with DBs, just separate the logic. Ones that have an interaction with the master db shouldn’t handle read operations and vice versa.