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