Why Use TOYS?
Manual processes are tedious and unreliable
Whether you are developing, refactoring or maintaining applications that use an Oracle® database,
your change processes are likely to be complex.
By using tools that automate the comparison and synchronization of your database schemas, you can greatly simplify the process of schema evolution.
As your schemas "evolve" you will be required to perform transformations of existing schema and the data contained within.
By using specialized tools to do this, your development processes can be greatly simplified.
Currently, you and your team probably work like this:
- Whenever somebody makes a change to a database object in your development database, you create a database change script.
If you are doing it right, you will store it in your source control system and label it with the appropriate change request number.
- When the project [or collection of change requests] is ready for acceptance testing, you collate all the different
database change scripts belonging to the required change requests and either:
- Merge them all into one large script -or-
- Write a control script to execute them in the correct sequence.
- You then test this script on a copy of the acceptance database to ensure it successfully upgrades it to agree with
your new data model.
- Quite likely, your upgrade script will fail, so you debug the script. Typically, over and over and ...
When you are finished, you pronounce that the database has been upgraded.
When a significant number of changes have been applied it is not always easy to be confident that you got it right first time!
For simple changes, this can be resonable but as the number of changes increases it is likely that someone will forget to create one
or more scripts.
Even if all of the scripts are carefully recorded and labeled, compiling and testing them can be a right pain. Even worse, sometimes
some of these changes [or parts of them] make it into the target databases.
This means that your compiled upgrade script is likely to fail.
Without special tools, this process is a good as it gets.
If you use this process, you have probably found that:
- Developers don't always create the scripts when they modify the database.
- Even when they do create these scripts, they often don't test them, so they don't work. Ah, just a small typo here ...
- You cannot be certain that the script(s) correctly upgrade the database.
You will just have to test your application and hope for the best.
Your acceptance testing is not only having to test the application changes but also the database upgrade scripts.
- To make matters worse, when the change scripts were created weeks [if not months] ago, you most
likely assumed that the database was in a certain state. What is to say that other development teams
have not "beaten you to it" and have already migrated their changes into acceptance or production?
Their changes could cause your migration script to fail.
- The whole process is extremely time consuming. How much time does each developer spend creating scripts for each
change? Add to this the time you have to spend creating and debugging the scripts for the migration.
You have to admit, migration scripting does consume a significant amount of a developer's time!
The process you have in place should:
- Improve quality
- Improve your efficiency.
If you're using the process described above, you've probably realized that it fails to meet either of these criteria.
A better alternative
If you haven't already used a tool to compare and synchronize your databases, try TOYS. So, rather than
laboriously creating individual DDL change scripts whenever you change a database object, try the following.
- When you are ready to migrate, use TOYS to compare your acceptance environment with your reference model and
to create a synchronization script.
- Run this synchronization script to change acceptance to agree with your new model. The synchronization script will
not only alter your schema structures, it will preserve the data in your tables and sequences when these are re-created.
- At the completion of the upgrade, you can use TOYS to compare your acceptance environment with your reference model to
assure yourself that acceptance is what it should be.
At this point, you can confidently hand over to the application testers knowing that your upgrade has been performed correctly.
- When you are ready to migrate to production, simply repeat the process.
Using an automated synchronization tool will save you hours of tedious work. It will also significantly improve the
quality of your deliverables.
Still not convinced?
To get a feel for what these synchronization scripts look like, take a look at
A simple example of synchronizing databases.
Copyright © Impact Systems Pty. Ltd. 2008
|