Comment Feed for Channel 9 - SQL Unplugged Episode 1http://video.ch9.ms/ch9/814f/b4d23dfd-a357-4ed6-b6a7-0b4ebd0a814f/SQLUnplugged01_220.jpgChannel 9 - SQL Unplugged Episode 1Welcome to the inaugural episode of SQL Unplugged, your avenue for asking question to, and talking with, the three individual who own the relational database at Microsoft; Shawn Bice, Nigel Ellis, and Rohan Kumar. In our very first episode, Shawn and Nigel answer questions and discuss topics around the new NextGen Azure SQL Database, and give us awesome insight into the history of SQL DB and the process to bring SQL DB to where is today. We get to hear their passion for SQL Server and the relational database as they talk about how far these great products have come! Starting in January our shows will be LIVE! enSun, 15 Sep 2019 12:47:30 GMTSun, 15 Sep 2019 12:47:30 GMTRev9Re: SQL Unplugged Episode 1
Nigel is money. That is all.

Any word on if/when cross-database scripting is coming? I think that would solve a big problem in lift-and-shift from SQL Server to Azure SQL Database. At least that's the case for my legacy On-Premise SQL Servers. Cross-database scripting is stupid and should never be used, but boy is it used out in the wild!

posted by HansOlavS

]]>
https://channel9.msdn.com/Shows/SQL-Unplugged/SQL-Unplugged-Episode-1#c635569420246976702
Thu, 15 Jan 2015 18:07:04 GMThttps://channel9.msdn.com/Shows/SQL-Unplugged/SQL-Unplugged-Episode-1#c635569420246976702HansOlavSRe: SQL Unplugged Episode 1Would be interested in hearing what moves are afoot to help finance industry get in the cloud, perception seems to be they can't \ too much hassle to get it done

]]>
https://channel9.msdn.com/Shows/SQL-Unplugged/SQL-Unplugged-Episode-1#c635569947289791628
Fri, 16 Jan 2015 08:45:28 GMThttps://channel9.msdn.com/Shows/SQL-Unplugged/SQL-Unplugged-Episode-1#c635569947289791628HansOlavSRe: SQL Unplugged Episode 1
@HansOlavS: with respect to cross DB scripting support, I'm assuming you mean the capability to run queries (and perhaps even transactions) that span multiple databases. Something say along the lines of "SELECT ... FROM dbA.x.tableA JOIN dbC.x.tableB". The reason we don't have this support in place today is due to the way Azure DB spreads the databases hosted on each logical server across different backend machines. This is why you can have large numbers of databases hosted in Azure DB whose combined resource requirements (CPU, IO, memory, storage, etc.) exceed the capacity of any single host machine.

In the short example above, an on-premise (or VM) SQL instance is able to process this as a local distributed query within the same physical instance. In Azure DB this becomes a distributed query/transaction spanning multiple servers - obviously more complex! We are making investments in areas to support flexible query and transactions at scale as part of our Elastic Scale work. The 1st part of this work is already in public preview and relies on client or self-hosted components. We are making further investments to enhance these scenarios and deliver some of these capabilities as part of the Azure DB service. This would include support for cross DB query (really no different than cross shard query). I would however stress that while this support will be extremely useful for many scenarios, it is not the same as full cross database scripting support. See [1] below to learn more about what we have in elastic scale today.

It's great to hear you are looking to build out this scenario. In a topology with multiple shards (hopefully) sharing the same schema, ideally most queries would be contained within each shard. However, in some cases a query spanning shards or relating together data between a shard and a common shared database (containing global data) is necessary. That's somewhat painful today. To the degree realistically possible, not having to write application-tier code to manually handle what most would consider a data tier concern would certainly make the Elastic Scale solution a lot more compelling.

For what it's worth, the other "pain point" of Elastic Scale is schema management. My hope is that existing solutions (SSDT, EF migrations, etc.) can gain "awareness" of Elastic Scale, and enhanced to support cross-shard schema changes. After all, every time "yet another schema management tool" (YASMT) is developed, a higher power sheds a tear!