Database Reference
In-Depth Information
Communication Foundation) Data Services client to access SQL Azure as well. Again, you have plenty of
options.
The benefit of using an Azure-hosted solution is the ability to minimize network latency of requests
to the SQL Azure database. Just as important is the fact that you're cutting the costs of data movement
between SQL Azure and the application. As long as your Windows Azure and SQL Azure are in the same
subregion, bandwidth usage between SQL Azure and Windows Azure is free.
By putting both your application and database in Azure, you also get the benefit of more efficient
transactions between your app and the database, because doing so minimizes the network latency
between your application and the database.
But you incur the compute cost, which is currently $0.12 per hour.
Compute hours
is the time your
application is deployed to Windows Azure. Even if your application isn't in a running state, you're being
billed. Billing is per hour, and partial hours are billed as full hours. When developing and testing your
application, you should remove the compute instances that aren't being used. Thus, the key here is
to
test locally before deploying remotely
.
Which to Choose?
The decision to move your application to the cloud versus keeping it local is entirely up to you and
shouldn't be determined solely by what you read in the last two sections. The decision isn't that cut-and-
dried. You need to look at several other factors, such as costs, data traffic, and bandwidth, and then base
your decision of the analysis of this information. For example, it may not be a sound decision for a small
company with little web traffic to host an application in Azure, due to the compute costs. However, that
same company can keep its database in Azure while keeping the application on-premise because the
data-transfer costs are minimal, yet gain the benefits of SQL Azure (failover, and so on).
In many companies, the initial goal isn't an all-or-nothing approach. The companies spend some
time looking at their databases and applications, decide what functionality makes sense to put in the
cloud, and test functionality on that. They test for performance foremost, to ensure that when deployed
to Azure in production, performance is in the same ballpark. The thought is to keep the important things
up front to ensure a successful Azure deployment. Roll your application out in pieces, if necessary, and
test locally prior to deployment.
Whether you deploy all or part of your database and application is for you to decide. Chapter 2
discussed the issue at length, and this chapter doesn't rehash it except to say that before you make a
decision, you should look at all the facts.
Connecting to SQL Azure
Developing applications that work with SQL Azure isn't rocket science, but it requires knowing what to
expect and what functionality you have to work with. You read earlier that not all client libraries work
with SQL Azure and saw the libraries that are supported. Chapter 5 also spent some time discussing what
T-SQL functionality exists in SQL Azure. Even as this topic is being written, the list of supported features
changes as Microsoft continues to add functionality. This chapter now focuses on a client application's
perspective.
This section looks at using several technologies to connect to and query a SQL Azure database,
including ADO.NET, ODBC, and WCF Data Services. You read at length earlier about taking the right
approach to move to the Azure platform. You must consider many things, including the following:
•
SQL Azure is only available via TCP port 1433.
•
SQL Azure doesn't currently support OLE DB.
