Refactoring the Model & Database Syncing
time to read 2 min | 333 words

Most of the interesting applications today talk to a database at one point or another. Unless you're writing a document centric client side application (think Word, Excel), you need to deal with databases.

And that is a problem. It's a problem because beyond this point, all your trusty tools leave you to forage forward on you on. A simple thing like a change of a field in the database may require a tremendous amount of effort to fix if you're not careful.

One danger that may occur if you subscribe to the school of thought of Continous Refactoring is that your domain model and the database model will grow apart. I recently had to change the name of a concept in my model. (Say, from Location to Position.)

It's very easy to do it on the code, and just as easy to leave the database in its current state (it's working, isn't it?). The problem is that while it's okay to map blog_author to Author, it's probably not okay to map user_location to Position. The cocepts has a slightly different meaning, and it's not very clear what the relationship is between the database and the model unless you look at the mapping.

I had some problems with getting a script from my databse (now solved ;-) ), so this was a real issue to me. I kept changing the database schema using VS 2005, but I had no way to get the scripts out. (Which would've allowed the use of the advance technique known as Search & Replace).

Anyway, the point of this post is that you need to pay attention to the database when you refactor the model. It's hard, especially if you've data in the database and not an empty structure. But letting the databse out of sync with the model is a sure way to get confustion along the road.

Tweet Share Share 0 comments
Tags: