Instalar scripts: crear tablas frente a actualizar las existentes

Tengo una pregunta, recientemente estaba desarrollando un módulo con muchas tablas en DB, y el concepto cambiaba con frecuencia, por lo que era necesario cambiar las tablas existentes en DB, y noté la diferencia en la creación de tablas y la actualización de tablas. Aqui tienes. Mira la creación de código de tabla a continuación:

$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
    )
);

la función newTable () devuelve una instancia de Varien_Db_Ddl_Table y la actualización del script de la tabla usa una forma diferente de agregar una nueva columna a la tabla existente, eche un vistazo:

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

Estas dos funciones addColumn son diferentes y también son métodos de diferentes clases, y me entristecen cada vez que necesito cambiar la sintaxis.
Entonces, aquí hay una pregunta, ¿hay alguna manera de actualizar la tabla existente usando la instancia de la clase Varien_Db_Ddl_Table ?

No parece haber una forma de modificar una tabla existente utilizando el objeto Varien_Db_Ddl_Table. Si ingresa al código de esa clase, no verá ningún área donde extraiga el esquema existente para la tabla, o verifique si la tabla existe de alguna manera. Eso sería necesario si fuera a usarlo para modificar la tabla.

Además, en Varien_Db_Adapter_Interface no hay ningún método similar a 'updateTable' que tome un objeto Varien_Db_Ddl_Table como parámetro.

Este es definitivamente uno de esos 'olores de código' en Magento, ya que tiene dos bloques de código completamente diferentes que intentan lograr lo mismo de diferentes maneras. Solo conducirá a errores.

Si está dentro del alcance del proyecto, es posible que desee considerar cambiar a un modelo EAV si el modelo está cambiando con mucha frecuencia como mencionó. Esto puede ahorrarle la molestia de confundir las migraciones de datos de un lado a otro. Aquí hay un artículo que explica los conceptos básicos de EAV en Magento para que pueda evaluarlo y decidir si es apropiado para su proyecto.