Redgate Change Control 4

Schema model

In v5, Redgate Change Control has been renamed to Flyway Desktop. Check out the latest documentation at https://documentation.red-gate.com/fd


With Redgate Change Control it is possible to capture database changes into a schema model on the Schema Model tab, which provides convenient object-level history in your version control system.

If you make changes to your development database and refresh the page, these changes should show up on the page.

If you select any changes you want to capture, and then click Save to project, each change will be saved as its own script within the schema-model folder under your project.

Following the Generate migrations button or clicking on the Generate migrations tab allows you to capture these changes as migrations.

Following the Commit changes button or clicking on the Version control tab allows you to then commit these changes to Git if your project is in a Git working folder.

If you pull down schema model changes from version control which have not been applied to your development database, you can apply them by clicking on the Apply to database option in the top left, selecting the relevant changes and clicking the Apply to database button.

Why should I version control my database schemas?

Version control is a good idea for a number of reasons:

  • You can keep track of changes to your database schemas
    • Find out the exact details of the change
    • Find out when the change happened
    • Find out who made the change
    • Find out why the change was made (using a commit message, which could be tied back to a user story or bug id)
  • You can share database schema changes
    • Share changes between team members on different development databases
    • Kick-off Continuous Integration (CI) and automated releases (e.g., to Test environments or more)
  • Get back to previous versions of an object

How does Redgate Change Control do it?

Normally, it's hard to version control database schemas because they're not text files. Version control only really works well for text files, because it's easy to tell what's changed in a text file. It's much harder to tell what's changed between two versions of other files, eg binary files.

Databases are just large binary files, so if you tried to version control one, your version control system wouldn't be able to tell what's happened when you make changes. This means you don't get most of the benefits of version control.

Redgate Change Control lets you version control the schemas of your SQL Server databases

It generates a version of your database schemas as text files, which you can link to your version control system. This means that, when you make a schema change and commit it to version control, it's easy to see what the change was. Redgate Change Control figures out how to turn that change into text files, including any dependencies. 

How is the schema model different from migration scripts?

Migration scripts capture the steps needed to deploy a schema to a clean database.

The schema model represents each object in its own script.

The migration scripts are safer to use for deployment as they are customizable and allow for the migration of transactional data while making changes to the schema.

The schema model is a representation of the schema information which allows for a richer version control history. It also allows for rapid iteration in development without generating a new script for every change.


Didn't find what you were looking for?