Designing Data Storage Architecture - SQL Azure - why use it and what makes it different from SQL se

http://blogical.se/blogs/jahlen/archive/2010/11/23/sql-azure-why-use-it-and-what-makes-it-different-from-sql-server.aspx

I've so far not seen any article on why anyone should use SQL Azure so I thought it is time someone writes about that. This article is an introduction to why you might be interested in a cloud database
and a summary of the differences compared to "ordinary" SQL Server. Finally I've included links to some useful resources.
Why would you need a cloud database?
Maybe you've read the story about the unknown IT multi-millionaire Markus Persson? If not,here
is an article (in Swedish only). He's not so unknown any longer but I think he never imagined what a tremendous success his game Minecraft would be. Even if he haven't spent a single
dollar on marketing it became so successful that the server capacity was not sufficient for the all the new paying players.
Of course it is very hard to predict how popular an online game or service will be. It can also change dramatically if you get good publicity (or bad).
How can you then make sure you always have the right server capacity for your users?
This is where Azure and the cloud comes in. It is an elastic platform which provides you the means to instantly increase or decrease your server capacity. You only pay
for what you use and don't have to estimate capacity needs and buy a reserve capacity. You won't run into the problem of "how can I do database maintenance when I always have millions of players online".
Database-as-a-service vs physical databases
What kind of demands can you make on a database? Why would anyone use a database? Would it not be easier to just write data to files instead?
I can give you at least four reasons why you should in most applications use a database:

Availability - let's say you are running business critical applications (like in healthcare). Then you don't want to rely on a single computer or disk. SQL Server comes with built-in support for high availability such as clustering, database mirroring,
etc which can be configured by a DBA. With SQL Azure you automatically get high availability with zero configuration.

Security - with a database you have a much finer control of security than on a file. You can also audit the usage, who has accessed what and who has updated what.
Auditing has become increasingly important since the last financial crisis.

Correctness - you can enforce consistency on a database through foreign keys, unique indexes, check constraints,
etc. Also you can use transaction isolation to prevent chaos when thousands of users work with the database simultaneously. In almost any OLTP application you need to use transactions if you want the application to work correctly with many users.

Performance - databases have several mechanisms to optimize performance such as caching, query optimizers,
etc.

I'm not saying that the above features cannot be achived by files and custom code, but with a database you needn't reinvent the wheel every time.
As a developer you just want the database features but probably don't want to spend time setting up clustering, applying security patches, worry about disk space, etc. Those are the things a DBA
does for you.



With SQL Azure you get at least three physical databases for every single database your create. That is how SQL Azure ensures you get the 99.9% uptime. Also you don't
need to spend any time on security patches, disk space, moving databases between different servers to handle increased load, etc.
SQL Server Consolidation
It has become increasingly popular to consolidate SQL Server databases, because it can save you money on hardware, licenses and maintenance work.



I've seen three main methods to consolidate databases:

Virtualization - which simply means moving physical machines to virtual machines. The easiest way, but also gives the least savings because every virtual machine needs its own OS and occupy a lot of resources.

Instance consolidation - which means that you move several SQL Server instances to the same physical server and let them share the OS. Better efficiency than virtualization, but still resources are not shared between instances.

Database consolidation - where you merge SQL Server instances. Even more efficient than instance consolidation.

I've added SQL Azure as a method in the picture above. It takes more effort than any of the other methods because SQL Azure is a bit different from a physical database but it also gives you the biggest
savings.
Some differences between SQL Server and SQL Azure
So what really are the differences between SQL Server and SQL Azure? You can find a list
of unsupported features in SQL Azure here. But what are the fundamental differences?

In SQL Server you usually rely on Integrated Security. In SQL Azure you have to use
SQL Server authentication.

In SQL Server an idle connection almost never goes down. If it does, there is usually a serious error.
In SQL Azure an idle connection goes down after 5 minutes
and can go down for a lot of other reasons than timeout. You need to think about this especially if you use connection pooling.

The default transaction isolation level in SQL Azure is READ_COMMITTED_SNAPSHOT while it is
READ_COMMITTED in SQL Server.
That can make applications behave differently.

There is no SQL Server Agent in SQL Azure. Therefore it does not provide any functionality that relies on the SQL Server agent, such as CDC or similar.

You
cannot currently backup a SQL Azure database. However you can easily copy them instead. But you don't have access to transaction log backups so you won't be able to restore the database to an arbitrary state
in time.

Heap tables are not supported in SQL Azure (except in tempdb). A heap table is a table which does not have a clustered index. This is not a big issue since clustered
indexes almost always are a much better choice than heap tables.

You cannot write cross-database references in SQL Azure. In SQL Server you can combine data from databases in the same instance.

Also you cannot access linked servers
in SQL Azure.

Default database collation in SQL Azure is SQL_LATIN_1 and cannot be changed. However Microsoft has promised support for other default database collations in the future.

Fulltext indexing is currently not supported in SQL Azure.

The above list may look long, but most existing applications that use SQL Server would work well also on SQL Azure. The most common issue I think will be
connection pooling and handling of lost connections. The second most common issue (for people who live outside of US like me) will probably be the
default database collation.
Tempdb in SQL Azure
When you start using SQL Azure you will notice that you automatically get a master database. Do you also get a tempdb database?
Yes, there is a tempdb database. However there are some limitations how you can access it. Which of the following queries do you think works?

CREATE TABLE tempdb.dbo.Test ( col1 int not null )

CREATE TABLE #Test ( col1 int not null )

CREATE TABLE ##Test ( col1 int not null )

Only the second option works.
As mentioned earlier you cannot write cross-database references (like the first option). The third option is forbidden because you cannot create global tempdb objects.
Can you have heap tables (non clustered) in tempdb? Yes you can.
Still it
doesn't support the SELECT INTO statement, which I believe was disabled because it creates heap tables.
Summary
SQL Azure is very useful for applications where you don't know how many users you will have in the future, since it provides you with the ability to scale up and down on demand. Especially with the
new SQL Azure Federation support (that I will write about later). Also it is of course a very useful storage platform for Windows Azure based applications.