...
None of this information should be useful, unless you are meeting a problem.
We've changed the database model for the following reasons:
- Tables were limited to 2 billion records, which was a (distant but uncertain) risk for our most notable customers, especially with the table of properties. Our new tables support IDs up to 9,223,372,036,854,775,807 records (inclusive).
- We've greatly improved the tracking of dependencies across baselines. We are extremely proud of this, hoping that the new behaviour will be invisible to the untrained eye.
- We've made it possible to add external properties to requirements, which we are demonstrating with the "Estimates" feature, and which we are going to expand with other features in the future.
Therefore, it was necessary to transfer all data from the older to the newer tables.
How it proceeds
- We are copying data from AO_32F7CE_AO* tables into AO_32F7CE_DB* tables.The reason is, AO tables were limited to 2 billion IDs, whereas the new tables are virtually unlimited. This is important so our loyal legacy customers don't run into this problem, and we can safely advertise being ready for large databases.
- When some data is migrated, we put a timestamp in "MIGRATIONDATE", and we never look at it again. Destroy it if you want! You can look into the "MIGRATIONMESSAGE" to see whether there was an issue.
- If a migration wasn't successful for a record, you can restart the migration, for all or for this record. We have designed so that the migration is only updates the target data, instead of deleting-and-recreating it, so, if you have already modified the target data, this is not a problem.
...