Chris Johnson

Visual Studio database projects (or SSDT projects) are often compared to other source control systems, and usually found wanting. The technology can be on the clunky side, and seems to throw up more obstacles to overcome and hoops to jump through than seems necessary. However, I will argue that these frustrations stem from a lack of understanding about the real purpose of the tool, and that if you start to think about the technology as a way to manage a code base, rather than just a source control tool, you will find all sorts of unexpected benefits. In this session I will take you through what I mean by that. I will begin by walking through exactly what a database project is doing under the hood, and how it relates to the deployed database(s). Once I've covered that I will move on to some of the additional benefits you get from this, including easier refactoring of objects, code validation, organisation of objects, and adding comments to objects you normally wouldn't be able to. Finally I will look at referencing other projects. This is probably something you have found quite clunky in the past, but if it's used right it can be a game-changer to how you develop. This section will discuss why this process can feel so clunky, but will focus on how you can use this feature to break your code out into re-usable modules similar to .NET class libraries. This talk assumes you have some familiarity with database projects. As such, it is a mostly theoretical talk with only one short demo.

In this session, phData will talk through their experiences dealing with migrations: how to plan for one, how to handle refactoring code, and the difficulty of auditing.