具有EF的多个SQL数据库-设计的好坏？

Question

Currently we have a large in house platform that makes use of a number of different SQL databases (all on the same server). We have always created new databases where we feel that the data is quite different/independant from what we are storing in the other databases. With this approach we have ended up having a number of different databases (most have 30-50+ tables), but inevitably there is always some connections required between them.

As we are using Entity Framework, any cross database queries are proving a real pain, we have tried a number of different approaches and I personally feel that the main problem is that EF just doesn't really work across multiple databases.

While I know that the answer is often "it depends" I'm interested in peoples ideas or views on this so really the question is

1. Should we combine all of our seperate databases into one large database?

2. Were correct to have split our data into different databases (even if EF doesn't work well with it)?

Answer 1

You say

where we feel that the data is quite different/independant from what we are storing in the other databases

and then

cross database queries are proving a real pain

If you're having to do many cross-database queries, then it's likely that the data isn't quite as independent as you thought, in which case it might make more sense to merge the databases.

On the other hand, if your cross-database queries are rare, then it might be ok. Without knowing the details of your domain model and what you've got in each database, it's hard to say. Examine the cases where you're making these cross-database queries, and look at why you're making them, and how often that happens. If it's important or frequent, then consider merging. If it's rare, or not performance-critical, or the hassle of merging the database far outweighs the hassle of writing these few cross-database queries, then it's probably fine. Be careful with that last point though - it might be easier to leave the databases separate now , but you may come across something in the future that would be much easier on a merged database. Have another look at what sorts of data you're storing in these databases and work out a list of all the scenarios where you might need cross-database querying. Then look at each of those scenarios and decide how likely it is to happen, and how much of a problem it'll cause if you don't merge the database. That should help you decide whether to merge.

If you do decide to merge, do it as soon as you can. Every day that passes without that merge is a day where people are writing code that'll have to be refactored when you do get around to merging. The sooner you do it, the easier it'll be.

Answer 2

How large a database are you talking about? How many tables / how many GBs? What is the type of data that goes in?

The answer as you guessed is most likely "It depends". But here I'd say no, splitting is probably not a right choice. If you are having to do cross database queries, most likely the data split is not correct. It might be better to split across databases in certain scenarios where the data is independent - like transactional and reporting, for example (but of course that requires a data sync from one to the other).

Have you considered separating the data in same database, but residing on different schema? That is what is usually done.