Benefits of the DB Ghost Process

Faster delivery

Faster delivery of the finished product with enhanced code quality, integrity and elimination of last minute panics at release time

Lower costs

Quicker delivery also means lower project costs

Reduced workload

You will never have to write any schema upgrade scripts again

Greater confidence

Developers can check in code with complete confidence that nothing else in the schema or data has been broken

A full and complete audit trail

Compliment your existing audit tools to help make your systems auditable and assist efforts to meet corporate governance requirements, such as Sarbanes Oxley and Basel II. You can now audit every single change that is made to the database code using your Source Management System's history and diff functions

Seamless teamwork and collaboration

Developers will know who is working on what by simply looking at the checked out files; this ensures no two developers are working on the same SQL code

Simple auditing of changes

No more having to text search upgrade script files whilst trying to track down that elusive change - it’s all there in one place. By having all the scripts as create statements means that you can see the real changes instantly without having to filter out the 'plumbing' statements. Best of all, the SQL changes are now first class citizens in the "change set" rather than being lumped together and hidden in a delta/change script.

Full utilization of your Source Control System

Your existing investment in your Source Management System is fully realized for SQL code. If you label the source code at regular intervals then you have a named, point-in-time view of your entire database

True snapshots

By simply baselining the set of CREATE scripts you are creating a snapshot of the desired schema at a point-in-time. This process is instantaneous in many source control systems and is, in every way, a better mechanism than taking a snapshot of a running database. A running database does not have an audit trail of who changed what, when and why - it is simply a respresentation of the current state of the schema.

Repeatable releases

You can have a target database that PRECISELY matches a baselined, labelled set of source in your Source Management System. Developers can concentrate on making the functionally required changes without having to worry about how the changes will be propagated