Several databases or one?

Question

MySQL

I ask you to resolve the dispute, give arguments, in view of the fact that my opinion as a specialist for the customer, apparently, does not mean anything, or I am not a specialist at all.

The client wants user data from a hotel database server, a separate database for user payment history, a separate database for news on the site, etc.
The argumentation is: "It's easy to write a database switch", "It's more reliable from hacks", "Fault tolerance", "There will be no freezes".

My arguments: x2 increase in the cost of the budget for development, testing and maintenance. The pointlessness of the whole idea, since there are tables (wow), caching, parallel access to different data, transactions and locks in case of access to the same data in case of access to the same data. Moreover, locks are needed only when data is changed, and when reading, parallel read requests pass without problems. Seamlessly run multiple queries on a single connection. And in the case of several databases, you need to constantly switch connections, which affects performance.

The site user edits his data and they are sent for moderation, but until they are moderated, the old data is displayed.
Tell me, why do old data and new data for moderation need to be split into two databases? How to build JOIN queries between two remote databases, when this is simply done when the data is in different tables?

Maybe I don't understand something. Please confirm or refute my arguments.

Answer 1

1. There shouldn't be any brakes from switching the database, as there seems to be a fairly well-divided area of ​​responsibility:
News and payments are not connected in any way, and the joins between them are something strange.
2. There really is a complication, but if you work a little with the architecture, it will not be catastrophic
3. Reflection on performance - you need to write benchmarks
4. Reliability will really increase, because you can separately host the database with news and the database with payments, and allocate more resources for payments . This way you can save on maintenance.
To be specific, you need to look at your project, so you'll have to deal with it yourself.

Answer 2

I'll put my 5 kopecks on the scales.
It seems to me to consider database - without consumers of this data is not entirely realistic.
I mean that we need to start from the business, how all these databases will live in consistency, since business data has dependencies.
User payment history - probably needs users, they are most likely stored in another place (in another database). News can also have dependencies (for example, comments, who? Users) It's hard to say unequivocally in this situation, I don't see the whole picture.
But .. It makes sense to store data in different databases when there is a conceptual separation.
For example, the history of payments is a special case, some payments. Payments can be isolated in a separate context and formalized.
It is necessary to proceed from the subject area, since it is obvious that your end users do not read directly from the database, there is still code that organizes this.
The scale of the project is unknown, if there is only one developer, then what advantage will the division give? It will simply introduce complexity, waste of time and money. If the business began to develop, then it is rather a need and not a philosophical question.
There is also an option, just to make bases in one monolithic project, but I have not seen this yet. There must be a good reason to deprive yourself of relationships between tables in a relational database.

Answer 3

It may also be related to legislation. For example, it is mandatory to store personal data on the territory of the Russian Federation; In this connection, the division of the database into such data makes sense.

Answer 4

Theoretically, the division into separate bases gives a potential scaling reserve, since bases can be spaced apart on different servers.
On the other hand, to work with interconnected data, distributed transactions will be required, which will immediately complicate the system architecture and application logic, eat up performance and reduce reliability.
The client must provide a list of additional work with approximate prices and terms.
If he agrees to wait and pay, then nothing can be done.
Plus, a list of added risks also does not hurt.