May 4, 2017 at 10:50 pm
Hi all,
We have a spider-web of SQL queries and SQL Servers joined by Linked Servers. We want to get rid of these so that we can migrate to Azure SQL.
I need suggestions/ideas/opinions on the best practice nowadays? I believe that Linked Servers are no longer a widely used practice (correct me if I'm wrong) and I wonder how others got rid of it.
What we are thinking is to create an API layer and use APIs to call multiple DBs and aggregate the data. This is a lot cleaner than calling a stored procedure that is dependent on multiple DBs via Linked Servers.
However, this approach takes a lot of effort as one would imagine (changing the architecture, coding effort for both the API and SQL stored procedures, etc.). Therefore, I would just like to validate if this is the best approach to go forward with.
Opinions and suggestions please? 🙂
May 5, 2017 at 6:30 am
Linked servers are, unfortunately, a very widely used practice. They're not a very widely recommended practice because of all the issues that they cause. However, they're so very convenient, making it so you don't have to move data around or duplicate it, that they get used all the time.
If you want to move to Platform as a Service SQL Database (as currently configured, changes are coming), you just have to unpick the threads of cross server queries. You have to assume no queries between servers (there is a way to do cross-database queries, but it's a little bit of work). Then do what's necessary. I'd suggest not picking a single approach for everything. In some cases, duplicating data will be better. In others, setting up a service so that the app can cross-connect data is a good choice.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply