Tantas pessoas tentam fazer esse tipo de coisa (esquemas de diferenças). Minha opinião é

• O código fonte vai para uma ferramenta de controle de versão (Subversion, CSV, GIT, Perforce...). Trate-o como se fosse código Java ou C, realmente não é diferente. Você deve ter um processo de instalação que verifica e aplica ao banco de dados.
• DDL É CÓDIGO DE FONTE. Ele também entra na ferramenta de controle de versão.
• Os dados são uma área cinzenta - as tabelas de pesquisa talvez devam estar em uma ferramenta de controle de versão. Os dados gerados pelo aplicativo certamente não deveriam.

A maneira como faço as coisas hoje em dia é criar scripts de migração semelhantes às migrações do Ruby on Rails. Coloque seu DDL em scripts e execute-os para mover o banco de dados entre as versões. Agrupe as alterações de uma versão em um único arquivo ou conjunto de arquivos. Então você tem um script que move seu aplicativo da versão x para a versão y.

Uma coisa que nunca mais faço (e costumava fazer até aprender melhor) é usar qualquer ferramenta GUI para criar objetos de banco de dados em meu ambiente de desenvolvimento. Escreva os scripts DDL a partir do dia 1 - você precisará deles de qualquer maneira para promover o código para teste, produção etc. Tenho visto tantas pessoas que usam as GUIs para criar todos os objetos e, na hora do lançamento, há um scrabble para tentar produzir scripts para criar/migrar o esquema corretamente que muitas vezes não são testados e falham!

Todo mundo terá sua própria preferência de como fazer isso, mas eu vi muito mal feito ao longo dos anos que formaram minhas opiniões acima.