The dedicated model is where each developer works on a separate copy of the database. 

Setting up

To start with, everyone installs SQL Source Control on their machine. This means they can all commit their changes.

Then, one person (it doesn't matter who) needs to link the database to version control and make the initial commit.

Next, the rest of the team can then get the latest version of the committed database:

• If they already have a copy of the database, they can link it to the same repository, then Get Latest.
• If they don't have a copy of the database, they can create a blank database, link it to the same repository, then Get Latest.

Workflow

Once you've linked your copy of the database to the repository, your workflow should look like this:

1. Get the latest changes using the Get Latest tab.
   This makes sure you're up-to-date before you start working.
2. Develop your changes.
3. Commit your changes so the rest of the team can get your changes. 

It's best practise to Get Latest before you start working on changes. This makes it less likely that your changes will conflict with anyone else's. 

History

The repository will contain everyone's changes. If you want to see how the database has changed, or see the history of changes to an object, you can view the source control history.

Conflicts

Sometimes, when two team members are working on the same object, there can be conflicts when you Get Latest.

You need to resolve the conflict before you can continue. For instructions, see Resolve and merge conflicts.

Benefits

• Because each developer is working in an isolated environment, there's no risk of accidentally overwriting someone else's changes. 
• You're free to develop complex changes that might cause other parts of the database or the application to break. If something goes wrong, it doesn't affect other developers.
• Visibility of what's been changing.

Drawbacks

• You need to maintain databases on every developer's machine.