In the past, much of the design focus included the reduction in size of the database, fields were limited, storage was at a premium and system design focused on keeping the system indexed and fast, reducing the load on the database server. Later, the size of the web pages became a premium problem, as DSL and dialup were common. Whatever the bottle-necks were at the time, that was the most cost-efficient target for designers. As technology has evolved, the “low hanging fruit”, has evolved with it.
The primary drawback of SQL Azure is speed. The application itself is extremely fast, but it is not on your local network, so the data has to travel across the internet to your webserver, and then on to the user’s browser. Often, an application will call to the database for information several times. A page displaying a purchase order may pull the header information at one spot, then the product information at another. This is called being, “Chatty”.
Our systems pull as much information as possible from database at one time, were applications on SQL Azure return datasets containing all the necessary information for that page. Additionally, we utilize caching services to maintain pre-formatted data in memory. This means that requests for large datasets can be sent with cache-dates, and Azure will simply return the updated information and advise the server to use the cached data.