Database Change Scripts – Mambo Style


One of the more traditional approaches to database development is where developers simply work against a shared database instance through SQL Management Studio or Enterprise Manager.  Changes are thought of, designed through a GUI interface, and DDL is created and applied right then and there.  If you've ever taken this approach, you already know it's full of challenges.  When you're ready to deploy the latest and greatest database schema, you simply script out the current schema and apply it to your target.  This is fine for the early stages of development, but as you progress, you realize that having your data "blown away" everytime you deploy due to DROP & CREATE statements becomes annoying and even unproductive.  And once you go to production, blowing away the data may not even be an option.


Application developers aren't plagued with this issue.  First of all, they're not faced with the burden of preserving large amounts of data simply because applications query this data, not store it.  Furthermore, they have the luxury of evolved and tightly integrated source control working against the most granular unit of development - the file.  So how can database development overcome some of these challenges?  Through mambo-style change scripts.


So what is mambo?  We'll get to the true meaning of the name in a minute, but what's most important are it's features:



  • Allows you to upgrade the schema of any database (even blank) to the tip revision.

  • Automates the upgrade process to avoid manual application of changes.

  • Preserves existing data during an upgrade.

  • Can upgrade the data itself by specifying how to transform existing data to the new schema.

  • Enables developers to work off of local instances on laptops or at home and "sync up" their work with everyone elses.  This feature is crucial in large projects.

Okay, enough reading, what is it?  Actually, nothing fancy.  It's simply a scripting method where changes are encompassed in sequenced change scripts (DDL) and applied, in sequence, against the current schema.  For example, John and Larry are both working from home.  John adds a new column to DimAccount called PreferredMember and scripts the change out as "0004 - Preferred Member Column.sql", and Larry also adds a new column to DimAccount called Currency and scripts the change as "0005 - Default Currency Column.sql".  The next morning, both John and Larry checkin their change scripts (whoever checks in last must change their number to 0030), and now whoever wants these changes simply executes them in order.  Here's a visual to better understand:



The key thing to remember about each change script is that they MUST USE ALTER STATEMENTS WHEREVER POSSIBLE.  There's two problems that still aren't addressed:  1) Considering that you could have hundreds of these scripts, how do you automate their application?  2) How do you know what's been applied and what hasn't?  This is where mambo comes in...Mambo is a tool that will compile each and every change script into a single "mambo" script such that a given change script is guaranteed to only run once.  It does this by inserting a record for each and every script it executes into a metadata table, and always checks this table before running each script.  Therefore, you can upgrade ANY database at ANY version to the tip revision.



Enough talk.  Download "Mambo Sample.zip" below and see for yourself.


Considerations:




  • Change scripts should avoid USE statements, and instead inherit the USE statement defined in the mambo template. 


  • Mambo should be compiled and deployed as part of your daily build and deploy process.


  • Unless an object is being created for the first time, developers should write change scripts.  Also, be wary of the change script Management Studio creates for you as it typically involves creating a Tmp table with the new schema and copying the data over.  If executing mambo on production, this could be a costly operation.


  • Always backup your database before applying mambo, even if it's a developer instance.  If you encounter an error, or something doesn't upgrade properly, you might lose your data (and time).

 

Mambo Sample.zip

Comments (4)
  1. Erik says:

    Wow, this is pretty snazzy, mambo snazzy.

    Everyone should use this!

    Erik

  2. Tim says:

    This is nice.  Thanks!  But, why the splitting between the GO statements?  If, for example, I have a table name with "GO" as a substring, it will kill everything.  Won’t the GO statements be handled if left in to be part of the meat of the EXEC() ?

  3. MSDN Archive says:

    The GO statements are parsed by the TSQL window, and are not a supported by the EXECUTE statement (will fail).  The other reason for the GO statements is that in order to track which query has executed and which hasn’t, you need to log the names of executed queries to a table and check if not run previously before executing again.

    You’re right about the GO statements.  This was just a shortcut I took.  The better approach would be to search for a more definitive patterns such as CRLF & GO & CRLF, Regular Expressions, or something else more robust.

  4. ホスト says:

    女性向け風俗サイトで出張デリバリーホストをしてみませんか?時給2万円以上の超高額アルバイトです。無料登録をしてあとは女性からの呼び出しを待つだけなので、お試し登録も歓迎です。興味をもたれた方は今すぐどうぞ。

Comments are closed.

Skip to main content