Working with SQL Server in Hybrid Cloud Scenarios. Part 2

As a rule, impersonal information is stored in a public cloud, and the personalized part – in a private cloud. The question thus arises – how to combine both parts to return a single result at a user’s request? Suppose there is a table of customers divided vertically. The depersonalized columns were included in the table located in Windows Azure SQL Database, and columns with sensitive information (e.g., full name) remained in the local SQL Server. Both tables must be linked by the CustomerID key. Because they are located in different databases on different servers, the JOIN statement will not work. As a possible solution, we have considered the scenario, when the linkage was implemented on the local SQL Server. It served as a kind of entry point for the applications, and the cloud-based SQL Server was set up on it as a linked server. In this article, we will consider the case when both, the local and cloud servers, are equal in terms of the application, and the data merging occurs directly in it, i.e. at the business logic level.

Pulling data from SQL Azure from the point of view of application code is no different from working with a local SQL Server. Let’s just say, it is identical up to the connection string. In the code below, u1qgtaf85k is the name of the SQL Azure server (it is generated automatically when it is created). I’ll remind you that the connection with the server is always established on the TCP/IP network library, port 1433. The Trusted_Connection=False parameter is not Integrated Security (it is always standard in SQL Azure), Trust_Server_Certificate=false is meant to avoid a possible man-in-the-middle attack.

Script 1

I will also add the connection with the on-premise resource, i.e. with the local SQL Server. I assume that this process does not require explanations, so let’s just modify the previous code by adding two methods – ExecuteSQL to connect to the source and execute a query against it, and DumpTable to somehow visualize the results. Thus, working with SQL Azure and on-premise SQL Server from the point of view of the application will occur absolutely symmetrically.

Script 2

Now that we have both vertical pieces inside the application in two DataTable instead of the single Customers table: one – from the local server, the other – from SQL Azure – we need to unite them by the CustomerID field, which exists there and there. For simplicity, we will not consider the case of a composite key, i.e. we will assume that the connection is made by a simple match of one column in one table with one column in the other table. This is a standard ADO.NET task. There are two most common ways to solve it, which are approximately equivalent in performance. The first method is using DataRelation. It is implemented in the JoinTablesADO method. Create a new DataSet, add both tablets to it, and create a relation (DataRelation) between them specifying the field in the parent and the field in the child table upon which JOIN will be built. Which of the two DataTable is the parent table and which one is the child table does not matter in this situation, because, in our case, the relationship is not one-to-many, but one-to-one. Create an empty workpiece for the resulting DataTable. Looping through all records of the “child” table, we get the corresponding record of the “parent” table and combine it from the fields of both DataRow records, which we then put in the resulting DataTable.

Script 3

The second method is using Linq. The idea is the same as in the first case. The difference is in the implementation details. First, we create a resulting table as a copy of the parent table structure. Then we add fields to it from the child table. We get the collection of records as a result of the Linq-request to the collection of records of the parent table by the link condition with the collection of records of the child table, which is then added to the resulting table.

Script 4