Creating a new SQL Server Database Project

In my previous post Migration-base vs State-based database development approach, I've shown two main approaches for database development. Today we will concentrate on state-based approach and learn how to start working with Microsoft Database Project.

Creating new project

Open Visial Studio → click 'File' → 'New' → 'Project'

If you are running Visual Studio 2017 navigate to 'Other languages' → 'SQL server' and select SQL Server Database Project.

After this operation Visual Studio will create an empty database project in the specified folder.

Creating table

To give good understanding for developers about business domains included into the project, the project should be well-structured. It is better to allocate specific schema for each of business domains and put all associated items (stored procedures, tables, triggers, etc.) with the schema in a separate folder. So let's create first business domain with the name 'Application'. At first we have to create folder with name 'Application' in solution. To do that, right-click on solution file → Add → New folder

After you create domain folder, let's create the file with schema. Right-click on 'Application' folder → Add → Script.

Specify an appropriate name for the schema file and make it part of build process. That will allow us to identify issues with SQL code during project compilation.

Application.Schema.sql code

CREATE SCHEMA [Application]
    AUTHORIZATION [dbo];

GO
EXECUTE sp_addextendedproperty 
    @name = N'Description', 
    @value = N'Tables common across the application. Used for categorization and lookup lists, system parameters and people (users and contacts)', 
    @level0type = N'SCHEMA', 
    @level0name = N'Application';

Now we are ready to create our first table. Let's create 'Tables' folder in 'Application' folder and create People table there.

People.sql code

CREATE TABLE [Application].[People] (
    [PersonID]     INT             NOT NULL,
    [FullName]     NVARCHAR (50)   NOT NULL,
    CONSTRAINT [PK_Application_People] PRIMARY KEY CLUSTERED ([PersonID] ASC)
)

GO
EXECUTE sp_addextendedproperty
    @name = N'Description',
    @value = 'Full name for this person',
    @level0type = N'SCHEMA',
    @level0name = N'Application',
    @level1type = N'TABLE',
    @level1name = N'People',
    @level2type = N'COLUMN',
    @level2name = N'FullName';

GO
EXECUTE sp_addextendedproperty
    @name = N'Description',
    @value = 'Numeric ID used for reference to a person within the database',
    @level0type = N'SCHEMA',
    @level0name = N'Application',
    @level1type = N'TABLE',
    @level1name = N'People',
    @level2type = N'COLUMN',
    @level2name = N'PersonID';

GO
EXECUTE sp_addextendedproperty
    @name = N'Description',
    @value = N'People known to the application (staff, customer contacts, supplier contacts)',
    @level0type = N'SCHEMA',
    @level0name = N'Application',
    @level1type = N'TABLE',
    @level1name = N'People';

Finally, we created our first SQL Server Database project. Congrats! Source code related to this tutorial could be found using following link https://github.com/aliakseimaniuk/blog-examples/tree/master/WideWorldImporters/01-Create-Database-Project.

Migration-base vs State-based database development approach

There are two main approaches for the development of SQL databases:

• Transformational (migrations)
• State-based (states)

Transformational or migration-based approach

The idea of the transformational approach is based on database migration from one state to another. After first production release, we will assume that database has its the first state. This state is the starting point for further migrations.

Why do I think that the starting point for migrations should be the first production release? The answer is simple. While the application has not gone into the production stage, it does not make much sense to try to save entered test data. Keeping data complicates development and testing process on earlier stages of project delivery. In this case, it is better to re-create the database each time and insert reference and test data into it. 

The diagram below describes the migration-based approach:

In this method, developers concentrate on writing migrations (M1, M2 .. Mn) from one database state to another (S1, S2 .. Sn). There is a good example of this approach. It is EntityFramework's migration mechanism. For more information, you can navigate and check MSDN article https://msdn.microsoft.com/en-us/library/jj591621(v=vs.113).aspx.

State-based approach

This approach is based on the following paradigm: developers have to maintain the most current snapshot of the database structure. What does it mean? The most convenient way to explain this is to analyze the following example. Let's assume that we have the table below:

CREATE TABLE People (
    PersonID  INT NOT NULL PRIMARY KEY CLUSTERED,
    LastName  VARCHAR(255) NOT NULL,
    FirstName VARCHAR(255) NOT NULL,
    Address   VARCHAR(255) NULL,
    City      VARCHAR(255) NULL
);

At some moment product owner decided to add one more property to the People table. In migration-based world in this particular scenario developer has to create migration script with ALTER TABLE Statement, but in state-base world we need to follow it's the main paradigm, so we need to update table creation script with a new column. Please see below.

CREATE TABLE People (
    PersonID  INT NOT NULL PRIMARY KEY CLUSTERED,
    LastName  VARCHAR(255) NOT NULL,
    FirstName VARCHAR(255) NOT NULL,
    Address   VARCHAR(255) NULL,
    City      VARCHAR(255) NULL,
    Country   VARCHAR(255) NULL
);

So developer needs to keep database structure up-to-date and the tools will do all the work. Cool, right? One of such tools was introduced by Microsoft when they shipped Visual Studio database project.
Let's see how these tools work. On the diagram below, you can find database development schema used by Visual Studio database project.

Microsoft Database project and tools inside of it will be trying to sync the database with current database script. For more info about Microsoft Database Project use https://msdn.microsoft.com/en-us/library/xee70aty(v=vs.100).aspx link.

What approach to choose?

It is difficult to say which approach is better or worse for a particular project. Next, I will give some advantages and disadvantages of each approach, which in my opinion play a key role in the choice of the mechanism for developing a database on the project. And you can decide what is the best for you.

Advantages of migration-based approach

• Understandable workflow of data migration
• Full control on generated SQL-scripts

Disadvantages of migration-based approach

• Need write the tool for deployment script generation or pay for existing one
• Developer's onboarding process require more time for understanding how database upgrade works
• The complex mechanism for keeping the database in the actual state. Developer has to revert database to valid state to perform migration because order of migrations is important

Advantages of state-based

• Gives developers access to the current state of the database
• It is easier to audit and view history of changes in source control
• Force developers to keep actual state of the database in source control
• Database script compilation, developers can identify issues with their code during compilation
• Can detect if somebody did manual changes in the production database and sync it with actual schema in source control
• Build-in mechanism for database refactoring

Disadvantages of state-based

• Developers do not have a lot of control over deployment script generation
• Poor support for user data migration
• Additional review of generated script required, developers have to check generated script before deployment