Databases Reference
In-Depth Information
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 whether to move your application to the cloud or keep it local is entirely up to you, and it shouldn't be
determined solely by what you've just 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 on 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, because of the compute costs. However, that same company can keep its database in Azure
while keeping the application on-premises because the data-transfer costs are minimal, and still gain the benefits of
SQL Database (failover, high availability, 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 the app is deployed to Winodws Azure in
production, performance is in the same ballpark as their on-premises solution. 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 Database
Developing applications that work with SQL Database 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 Database and
saw the libraries that are supported. Appendix B will spend some time discussing what T-SQL functionality exists in
SQL Database. Even as this topic is being written, the list of supported features changes as Microsoft continues to add
functionality. This chapter focuses on a client application's perspective.
This section looks at using several technologies to connect to and query a SQL Database instance, 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 Database is only available via TCP port 1433.
•
SQL Database doesn't currently support OLE DB.
•
SQL Database only supports SQL Server authentication. Windows Authentication isn't
supported.
•
When connecting to SQL Database, you must specify the target database in the connection
string. Otherwise, you're connecting to the
master
database.
•
Distributed transactions (transactions that affect multiple resources, such as tables, or
different databases via sharding) aren't supported in SQL Database.
•
You must ensure that your SQL Database firewall is configured to accept connections.
