a target database, SSDT will determine what it needs to do to make
your target look like the schema that you’ve defined.
To help you understand this concept, let’s look at an example.
Imagine I have the following table defined in my SSDT project:
CREATE TABLE [dbo].[Product]
(
[ProductId] INT NOT NULL PRIMARY KEY
, [ProductName] NVARCHAR( 30) NOT NULL
)
I decide I want to make a couple of changes. I want a new column
to store a category, and I want to assign a name to the primary key:
CREATE TABLE [dbo].[Product]
(
[ProductId] INT NOT NULL
, [ProductName] NVARCHAR( 30) NOT NULL
, [Category] NVARCHAR( 30) NULL --New column
, CONSTRAINT [PK_dboProduct] PRIMARY KEY ([ProductId])
Download
Download the code
After I publish the project, SSDT generates the script in Listing 1 to
effect the required changes.
The script makes the appropriate changes to the deployed table
while respecting the presence of any data that might be stored within
it; it’s fairly complex, to be sure, but that’s not the point. In fact,
under normal circumstances, the DBA or database developer would
never even see this script because SSDT generates and executes it
transparently during a publish operation (don’t panic—you have the
option for SSDT to just generate the script and not execute it).
