Headspring
agile. software. consulting.

Database Development

Best Means for Schema Scripts

Headspring does not recommend generating SQL scripts from code. Headspring does not recommend writing SQL either. SQL generation from mapping files or from changes to an instance of a database makes for a cleaner approach.

Redgate SQL Compare is a superior tool for comparing two snapshots of a database (i.e., a project schema before a modification and the project schema after a modification) and for generating a change script based upon the discrepancy. Redgate SQL Compare is superior to Microsoft SQL Server Management Studio Express as it generates transactional scripts with contingency logic for rolling back modifications in the event of a midstream error.

The Tarantino Approach

Headspring's own have contributed to The Tarantino Project, an open source project for .NET which collects many useful .dlls such as those for NHibernate and NAnt into a common toolkit allowing the best of ALT.NET to be downloaded in one convenient library. Beyond collecting technologies, the project offers an impressive means for managing database changes.

In the following video presentation, Jeffrey Palermo and Eric Hexter speak to the DB-related powers of the Tarantino Project and contrast it with other Database Frameworks/Tools, namely: Rails Migrations, RiskMigrations, SubSonic Migrations, Migrator.NET, and Machine Migrations. One big difference is that there is no down migration with Tarantino... only up migration. This is because every step forward is a solid step forward using Tarantino's methodologies.

Questions that Tarantino Answers:

  • How does one know what the database schema truly is? Does anyone have the SQL behind the current production database?
  • Shouldn't developers interact with the database in a sandbox just as they interact with the code? No one would ask developers to universally open the same .sln file across a network share to enable a team to work on the same codebase. Isn't it just as inappropriate to have all developers interacting with a common database at a server?
  • How can integration tests be run without compromising existing data? (This point speaks to the one above.)
  • What if one's integration logic changes, and NHibernate is employed instead of Entity Framework, for example? How will the SQL generation be effected?
  • How may a team manage the history of SQL scripts run to build a schema?

 

Intrigued?
Contact us to learn more.

 

© 2001-2010 Headspring. All rights reserved.
Proudly headquartered in Austin, Texas