"Alter" has the advantages that it is not dependent on the underlying
DBMS architecture, and is more likely to have the correct results than
simply altering system tables.

Vulcan is promising some non-trivial cleanups, so writing to system
tables instead of using the appropriate DDL could easily leave you
unable to upgrade your app at some point.

Repeatability requirements in my pet application demand that business
logic versions be maintained. So, given a business object class
"Contract", data version 1, code version 1, I actually have a table
CONTRACT_001 which stores data from any Contract_001_xxx version
object.

The reasoning is, since data structure is less volatile than code, data
versioning is the most significant sub-identifier. When data version
changes, a new table "CONTRACT_002" is created. If objects are
upgraded, they are represented in the new table with the same ID as the
original object, but the newest object version number. From previous
postings about audit trails, I guess it is apparent that the old data is
marked as inactive but it is never removed from the database.

The Object Relational Mapper layer of the application is responsible for
tying classes to the correct tables. I actually use Hibernate for this.

Hope this helps.

On Tue, 2005-06-28 at 20:18 -0300, Gustavo wrote:
> le changes and the solution I thought for each one:
>
> A new field was added: ALTER TABLE table ADD ...
> A field was discarded: ALTER TABLE table DROP ...
> A new index was added: CREATE INDEX ...
> An index was discarded: DROP INDEX ...
> A field has changed (length, etc.): I didn´t found a statement like
> ALTER FIELD so I though of modifying RDB$FIELDS with UPDATE
> statements.