the latest evolution of a product line that has existed in various incarnations since Visual Studio 2005. Those incarnations include Visual
Studio Team System for Database Professionals and Visual Studio 2010
SQL Server Database Projects, plus some more colloquial names, such
as “Data Dude,” “TSData,” and “DB Pro.” If you’ve used any of those
products, you’re well set for coming to grips with SSDT; if you haven’t
used any of those products—well, you’re reading the right article.
A note for readers who are familiar with SSDT’s previous incarnations: The data-generation and unit-testing features in those products
have been removed in SSDT. Those features might return in the future;
however, nothing has been announced at the time of this writing.
Another side note: I have often seen or read remarks that suggest
some folks mistakenly believe that SSDT and its predecessors rely on
Microsoft’s application lifecycle management product, Team Foundation Server (TFS). That isn’t the case; you don’t need to be using TFS
in order to use SSDT.
Aims of SSDT
SSDT is an attempt to bring similar tools and consistency to SQL
Server development to what .NET developers have had for years. Features such as IntelliSense, code refactoring, code navigation, find all
references, sandboxed development and deployment, MSBuild support, and ease of deployment will be familiar to most .NET developers. However, the majority of these features are alien to many SQL
Server developers who’ve become adept at toiling in SQL Server Management Studio (SSMS). SSDT aims to change that.
A New Paradigm: Declarative Database Development
In addition to bringing the aforementioned new features, SSDT pushes
a new development paradigm: the notion of declarative database
development. Put simply, declarative database development means
that you define within SSDT what your schema looks like. Then,
when you deploy (or in SSDT parlance, publish) your SSDT project to
www.sqlmag.com
sql server Pro / may 2013
