Scripts de instalação: criando tabelas versus atualizando os existentes

tiver uma pergunta, recentemente eu estava desenvolvendo um módulo com muitas tabelas no DB, e o conceito estava mudando com freqüência, então havia necessidade de alterar as tabelas existentes no DB e notei diferenças na criação de tabelas e na atualização de scripts e tabelas. Aqui está. Veja a criação do código da tabela abaixo:

$table = $installer->getConnection()
    ->newTable($installer->getTable('module/table'))
    ->addColumn('id', Varien_Db_Ddl_Table::TYPE_INTEGER, 9, array(
        'nullable' => false,
        'primary' => true,
        'identity' => true,
        'auto_increment' => true
    )
);

a função newTable () retorna a instância de Varien_Db_Ddl_Table. E a atualização do script da tabela usa uma maneira diferente de adicionar nova coluna à tabela existente, veja:

$installer->getConnection()
    ->addColumn($tableName, 'test', array(
        'nullable' => false,
        'length' => 9,
        'type' => Varien_Db_Ddl_Table::TYPE_INTEGER,
        'comment' => 'Test Field'
    )
)

essas duas funções addColumn são diferentes e também são métodos de classes diferentes, e elas me deixam triste toda vez que preciso alterar a sintaxe.
Então, aqui está a pergunta, existe uma maneira de atualizar a tabela existente usando a instância da classe Varien_Db_Ddl_Table ?

Não parece haver uma maneira de modificar uma tabela existente usando o objeto Varien_Db_Ddl_Table. Se você digitar o código para essa classe, não verá nenhuma área onde ele puxa o esquema existente para a tabela ou verifica se a tabela existe de alguma forma. Isso seria necessário se você o usasse para modificar a tabela.

Além disso, em Varien_Db_Adapter_Interface, não há método ao longo das linhas de 'updateTable' que use um objeto Varien_Db_Ddl_Table como parâmetro.

Esse é definitivamente um daqueles 'odores de código' no Magento, pois você tem dois blocos de código completamente diferentes tentando realizar a mesma coisa de maneiras diferentes. Só levará a erros.

Se estiver dentro do escopo do projeto, convém mudar para um modelo EAV se o modelo estiver mudando com muita frequência, como você mencionou. Isso pode poupar o trabalho de confundir migrações de dados. Aqui está um artigo que explica os conceitos básicos do EAV no Magento para que você possa avaliá-lo e decidir se é apropriado para o seu projeto.