Refresh database is an workflow that allows you to develop with a migrations framework, but deploy with SQL files. It’s more than that, it allows you to rapidly make changes to your environment and sync up with other teammates. When I am talking about environment, I mean your local development environment: your code base and the local database back end you are hitting.

Refresh database comes in two flavors, one for NHibernate and one for Entity Framework. I’m going to show you an example of the one for Entity Framework, which you can find in the repository for rh-ef on github. One note before we get started: This could work with any migrations framework that will output SQL files.

What is this? Why should I use this?

How long do you spend updating source code and then getting your database up to snuff afterward so you can keep moving forward quickly? Do you work with teammates? Do you have multiple workstations that you might work from and want to quickly sync up your work?

It’s a pain most of us don’t see and an idea that was originally incubated by Dru Sellers. He wanted a fast way of keeping his local stuff up to date right from Visual Studio. Out of that was born Refresh Database. We are talking a simple right click and debug to a synced up database.

Others have talked in the past about how you want to use the same migration algorithm and test it all the way up to production. Refresh DB allows you to test that migration from a local development environment many times a day. So by the time you hand over the SQL files for production (or use RoundhousE), there is no guess work about whether it is going to work or not. You have a security in knowing that you are good to go.

It’s definitely something that can really speed up your team so you never hear “I got latest and now I’m trying to sync up all the changes to the database.” This should be easy. This should be automatic.

You should never again hear “I made some domain changes but now I’m working to get them into the database.” This should be easy. This should be automatic.

Whether you decide to look further into this or not, it doesn’t matter to me. It just means my teams will get to market and keep updated faster than you (given the same technologies, ).

How does this work?

This is the simple part. Convincing you to look at it in the first place is the hard part. I have put together a short video to show you exactly how it works. You will see that it is super simple.

Conclusion

Refresh Database has been around for over two years. It’s definitely something that has paid for itself time and again. It’s something you might consider looking at it if you have never heard of it.

If you don’t do something with migrations and source control for your database yet, please start now. This will save you countless hours in the future. I’ve walked into more than one company that was hurting in the area of database development b/c they didn’t treat the database scripts as source code in the same way that they did the rest of the code. It’s a must anymore. I also see teams doing shared development database development. This is a huge no no (except in certain considerations) due to the amount of lost time it causes. That however, is a discussion for another day.

Feedback

Refresh Database would be pretty cool if it didn't rely on and ORM. Especially NHibernate or EntityFramework which are soooooo slooooooow. EF is great for rapid prototyping but before moving to production on anything more than a trivial app where performance is even remotely important I strongly recommend stripping out EF and coding directly against ADO.NET connection and command objects.