I've been searching for a while how to solve this problem, and finally I've decided that maybe it's better to ask for some help.

We have two different application (app1 and app2), each of them with a different database (db1 and db2). Then we have another project to manage those applications data using both databases. This would be app3 with db1 and db2.

In db1 we have a clients table to set which client have active which application. Exemple: client 1 has active app1, client 2 have active app1 and app2, and so on... this is managed from app3.

The problem is that in app2 we need to access to this table in db1 to know if the user has that application active to log in.

We were thinking to separete this table in another database, but as we are not database experts we are wondering if there is any other better solution to solve this.

It's possible that in the future will exists a forth application with same clients and different database so we'll have the same problem. And duplicate clients it's not an option.

We're using SQL Server and .NET Core.


  • 1
    Hi and welcome to the forum! Do a search for "SQL Server cross database query".
    – Vérace
    Jan 8, 2021 at 9:06
  • Hi! thanks! mmm no, I haven't, because I wasn't sure that having a third database was the correct approach, but I'm going to check. Thanks! Jan 8, 2021 at 9:48

2 Answers 2


It is possible to query across multiple databases in SQL Server if all the databases are on the same instance, or there are linked servers set up between them. The login would need access to all the databases.

For your design question, I think having a third database for the separate concern of the client connections makes sense. This would allow the apps to focus on their specific data requirements in their databases and the client connections requirement focus on just that without crossing domains too much.

  • Great, thanks! the login it's not a problem, since each app have different users. I'll check about the linked servers to see how that works, but at least for now it would be the same instance. Jan 8, 2021 at 14:00

As others have pointed out, you're allowed to access Tables, Views, Stored Procedures, Functions, and most other objects across databases with cross-database querying. So from that standpoint you shouldn't run into any issues regardless of where you put the table.

It moreso comes down to the business logic and management reasons of whether you want to put that table into its own database. I've done it both ways and personally (at least for non-big data scaling / high workload apps) I like to keep all my business application tables under the same database but use a different schema for each application.

So in your context there would be a BusinessApplicationsDatabase, and a schema for App1, a separate schema for App2, and the default schema dbo (or you can make your own schema too) would be for universally used tables. Doing it this way organizes the data objects better, in my opinion. It also allows them access to objects that are not available cross-database, such as User Defined Types (whether those are good practice to use is for another discussion, but as an example). It also makes the database more portable and manageable in regards to backups and syncing or moving it to other servers. Additionally, security management within the database server becomes a little bit better in a sense that you have the granularity to GRANT and DENY permissions for a schema, but you only have to map your Users to one database instead of multiple.

The use cases where I wouldn't do that kind of design necessarily is if I know one applications data is going to grow at a much larger scale much more quickly than the other applications, and you want to separate the management of the growth of the database files. More so, if you need to replicate the data of one application across multiple servers with AlwaysOn Availability Groups, then having separate databases is better (again unless the data isn't large) since AlwaysOn Availability Groups synchronize whole databases. But these are more edge cases in my opinion, and less common the previously mentioned benefits of keeping things within the same database but leveraging the power of schemas.

  • 1
    Great answer, thanks! I've been thinking about using schemas, as you suggestted to see if it fits, but I'm not sure if in a long term would be a good solution. One of the apps it's bigger than the other one and it countinue growing, and it's possible that we add more apps. So, probably it's better to separate, as you said :) Jan 8, 2021 at 13:56
  • @IsisG.Benet No problem! If you have any other questions, feel free. I personally still like keeping things under the same database unless they are completely unrelated (e.g. when you're a consultant hosting the databases of different applications for different clients, then the applications have 0% chance of crossover). The only reason I think space management should be taken into consideration too is because I previously worked in the finance industry where our databases we're terabytes big, with tables that had 10s of billions of rows, and some of the common data objects and functions...
    – J.D.
    Jan 8, 2021 at 14:03
  • ...needed to reside in multiple servers (because we horizontally scaled our operations into multiple servers), and we used AlwaysOn Availability Groups for resiliency, so it made sense to house that small common schema in its own database instead of duplicating terabytes of data. But to each their own, it's definitely a question of preference too.
    – J.D.
    Jan 8, 2021 at 14:05

Your Answer

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

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