SQL Unplugged Episode 1

Sign in to queue

Description

Welcome 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!

Embed

Download

Download this episode

Download captions

The Discussion

  • User profile image
    dunnry

    Nigel is money.  That is all.

  • User profile image
    HansOlavS

    Cool stuff! Love SQL Server and the new Azure V12 Preview.

    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!

  • User profile image
    Andy Ball

    Cool show , interesting re stretch database concept

    Would 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

  • User profile image
    HansOlavS

    Shawn and/or Nigel: See 2 posts up! Any comments on my last questions?

  • User profile image
    nigelemsft

    @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.

    @dunnry: [H]

    Thanks,
    Nigel.

    [1] https://azure.microsoft.com/blog/2014/10/02/introducing-elastic-scale-preview-for-azure-sql-database/

  • User profile image
    compupc1

    @nigelemsft

     

    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!

  • User profile image
    HansOlavS

    @nigelemsft: Thanks for answering! Cross-db scripting is an anti-pattern, but a lot of enterprise stuff out there has anti-patterns ;)

Add Your 2 Cents