Instaluj skrypty: tworzenie tabel a aktualizowanie istniejących

mam jedno pytanie, ostatnio opracowywałem jeden moduł z dużą ilością tabel w DB, a koncepcja często się zmieniała, więc musiałem zmienić istniejące tabele w DB i zauważyłem różnicę w tworzeniu skryptów i aktualizacji tabel. Proszę bardzo. Spójrz na tworzenie kodu tabeli poniżej:

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

funkcja newTable () zwraca instancję Varien_Db_Ddl_Table. A skrypt aktualizacji tabeli używa innego sposobu dodawania nowej kolumny do istniejącej tabeli, spójrz:

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

te dwie funkcje addColumn są różne, a także są metodami różnych klas i zasmucają mnie za każdym razem, gdy muszę zmienić składnię.
Oto pytanie, czy istnieje sposób na aktualizację istniejącej tabeli przy użyciu instancji klasy Varien_Db_Ddl_Table ?

Wydaje się, że nie ma sposobu na modyfikację istniejącej tabeli przy użyciu obiektu Varien_Db_Ddl_Table. Jeśli przejdziesz do kodu dla tej klasy, nie zobaczysz żadnego obszaru, w którym pobierze on istniejący schemat dla tabeli, lub sprawdzi, czy tabela istnieje w jakikolwiek sposób. Byłoby to wymagane, gdybyś używał go do modyfikowania tabeli.

Ponadto w interfejsie Varien_Db_Adapter_Interface nie ma metody zgodnej z „updateTable”, która przyjmuje obiekt Varien_Db_Ddl_Table jako parametr.

Jest to zdecydowanie jeden z tych „zapachów kodu” w Magento, ponieważ masz dwa zupełnie różne bloki kodu, które próbują osiągnąć to samo na różne sposoby. Doprowadzi to tylko do błędów.

Jeśli jest to objęte zakresem projektu, możesz rozważyć zmianę na model EAV, jeśli model zmienia się bardzo często, jak wspomniałeś. Pozwala to zaoszczędzić kłopotów z pomieszaniem migracji danych tam iz powrotem. Oto artykuł wyjaśniający podstawy EAV w Magento, abyś mógł go ocenić i zdecydować, czy jest odpowiedni dla twojego projektu.