As I work on PolyBase Revealed, I made a conscious decision to prefer Azure Data Studio for my demos over SQL Server Management Studio. Because I don’t plan to go into much detail on why in the book (after all, the book is about PolyBase, not SQL Server clients), I wanted to take a little time and walk through some of my reasoning for this.
It’s Cross-Platform
One of the main use cases for PolyBase is to integrate with all kinds of data sources, including Hadoop, Oracle, Teradata, and the like. And on many of those platforms, Windows is a second-class citizen. The ability for me to give a native Linux or Mac user a useful platform helps with bringing them into the fold.
SSMS Has Limited PolyBase Support
SQL Server Management Studio does have some PolyBase-related functionality: you can see external tables in their own folder; you can right-click and get templates for new external data sources, file formats, and tables; and you can see the members of your PolyBase Scale-Out Group. If you are primarily focused on PolyBase, there’s nothing in that list which pushes me to say that you absolutely need SSMS.
Tables Are Tables
The Azure Data Studio team made a decision which I think is the right one: external tables are just tables. In SSMS, all external tables show up in their own folder, hidden away from everything else. But the idea is that PolyBase allows for data virtualization, meaning I don’t care where the data lives as long as it gets to me.
Azure Data Studio is New
This is a little bit of a stretch, but not as much as you might think. Azure Data Studio is a new product, so it’s easier to influence the product team. If the tens of millions of eventual readers of the book use Azure Data Studio for some of their work, that makes it easier to vote up PolyBase-related issues and feature requests.
36 Chambers - The Legendary Journeys: Execution to the max! 