The way I look at it, is that if you develop for Azure SQL DB, it’s going to run pretty much anywhere and if it happens to be on a low latency network, all the better.
I hate seeing hardware being used to mask code issues. The biggest problem is frameworks (and apps built on them) that encourage chatty behaviour. Worse are frameworks that are poorly configured. Recently I saw one where for every command, instead of just executing the SQL command, the framework did this: 1. Create a cursor for the command 2. Perform a fetch on the cursor to get the data 3. Perform another fetch on the cursor (which failed) 4. Close the cursor 5. Create the same cursor again 6. Use it to query the parameters and data types 7. Close the cursor again. And it did this ON EVERY SINGLE COMMAND <sigh> But even at a large customer that I was at a week or so ago, every command did this: 1. sp_prepexec the command 2. Retrieve the handle for the command’s execution plan 3. Execute the command based upon the handle 4. <some time later> unprepared the command. And the way they handled transactions was: 1. Turn on implicit transactions 2. Perform commands that might or might not do things that should be transactional 3. Regularly execute code that performed a commit, if there happened to be a transaction, and often some time later. In a trace of 250,000 SQL batches, over 180,000 were part of this “transaction management” Apps like these will never work properly in cloud-environments of any type, but the problem isn’t the cloud environment. Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com/> |http://greglow.me<http://greglow.me/> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Craig van Nieuwkerk Sent: Saturday, 28 January 2017 4:50 PM To: ozDotNet <ozdotnet@ozdotnet.com> Subject: Re: Used Azure SQL DB? Why or why not? I have been using SQL Azure for about 4 years for our SAAS app. All development is done against an on premise SQL Server so there is no problem if we lose internet. Developing against a remote DB would be painfully slow anyway. The biggest issue I find is that SQL Azure will highlight any performance issues than can often be masked by an on premise solution where the answer to performance is to throw more hardware at it. We use Visual Studio database project to manage the schema so migration is pretty painless. Craig On Sat, Jan 28, 2017 at 4:06 PM, Greg Keogh <gfke...@gmail.com<mailto:gfke...@gmail.com>> wrote: I haven't used SQL Azure in a live app yet, but have some personal and testing DBs up there. In a couple of weeks I'll share a DB with another developer who lives over an hour drive away, so instead of swapping zips of DB backups, we'll now connect to the same Azure DB, which is really convenient and easy. Watch the cost ... I mentioned this last year that a low performance DB can be about $30/month, and hundreds/month at the upper end. All our DBs are cheapies because luckily we don't need high performance or capacity. Desktop apps connecting directly to Azure DBs can suffer if you do stupid things like select thousands of rows to put in a grid. In this case don't design apps that demand huge slabs of data (or use async wisely). If your whole suite is in the cloud where public Azure services are privately querying the Azure DB then it of course it's blazing fast. Over the last year I have tried to convince or suggest to several people that they consider putting their DBs into the cloud, and in every case I have been met with resistance sometimes bordering on hostile, or even mockery. So clearly there is a perception problem that may take some time to break down. I pointed out that using SQL Azure or similar would mean they no longer needed to buy, install and manage the software, or buy a whopping great box, air-conditioner, power backup and case of failure, and they can scale up or out as needed, etc, but it all falls on deaf ears and everyone chickens out. Tony was worried about internet connection stability leaving people idle, but I reckon if your internet is down everyone stops working anyway and it's a disaster. Develop on a local DB. In summary, I'm biased because I'm utterly sick of hosting software myself when it can done by someone in the cloud where I have little worry about failure, security or performance. In recent years I've moved 5 web sites, 2 SQL databases, most backups, email forwarding and email into online hosting, and it's bloody fabulous as I have less and less to manage and worry about on the office LAN and server. Only one web site I host is preventing me from actually removing my server completely (due to dependence on native DLLs), but I'm working on getting rid of it soon. I'll buy one of those quiet little media boxes to hold my gigawatts of music and videos. Greg K On 28 January 2017 at 13:30, Tony Wright <tonyw...@gmail.com<mailto:tonyw...@gmail.com>> wrote: Hi Greg, The main thing I think stopping us has been on premises sql or dev edition sql. It just doesn't make sense to rely on the stability of the internet when developing, and an existing environment or dev edition is very little cost. The other issue is that it ends up in an account belonging to a single person rather than being an organisational account. The places where we've used Azure sql is when we've all wanted to all be able to access the database remotely with simplicity. The main business driver for using sql Azure as opposed to on premises sql had been more about wanting sql to operate in a DMZ, nowhere near the organisation's confidential on premises data. That said, we've just moved one application to using Windows Azure (started with table storage, moved to blob storage) simply because of the significant drop in cost of data. Regards Tony On 28 Jan 2017 1:19 PM, "Greg Low (罗格雷格博士)" <g...@greglow.com<mailto:g...@greglow.com>> wrote: To my developer buddies: I'm preparing a session for Ignite where I'm discussing using Azure SQL DB for greenfield (new) applications. Would love to hear opinions on if you've used it, and what you found/learned, and if you haven't used it, what stopped you ? Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775<tel:1300%20775%20775>) office | +61 419201410<tel:+61%20419%20201%20410> mobile│ +61 3 8676 4913<tel:+61%203%208676%204913> fax SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com/> |http://greglow.me<http://greglow.me/>
