Comments on: Database Refactoring https://thomaslarock.com/2012/08/database-refactoring/ Thomas LaRock is an author, speaker, data expert, and SQLRockstar. He helps people connect, learn, and share. Along the way he solves data problems, too. Fri, 21 Dec 2012 03:32:27 +0000 hourly 1 https://wordpress.org/?v=6.7.1 By: It's Christmas: 3 Ways To Be Wise About Your Rowsize | SQLRockstar | Thomas LaRock https://thomaslarock.com/2012/08/database-refactoring/#comment-7737 Fri, 21 Dec 2012 03:32:27 +0000 http://thomaslarock.com/?p=9134#comment-7737 […] possibly leftover from a refactoring project that never got cleaned up. Yeah, go ahead and pretend like you’ve worked on a refactoring project that actually cleaned up the old data. I’ve yet to meet anyone that has seen such project through to completion, many projects […]

]]>
By: Database Refactoring « 36 Chambers – The Legendary Journeys: Execution to the max! https://thomaslarock.com/2012/08/database-refactoring/#comment-7361 Fri, 14 Sep 2012 22:06:32 +0000 http://thomaslarock.com/?p=9134#comment-7361 […] Tom LaRock is not a fan of database refactoring. […]

]]>
By: Eric Wise https://thomaslarock.com/2012/08/database-refactoring/#comment-7262 Tue, 14 Aug 2012 03:56:00 +0000 http://thomaslarock.com/?p=9134#comment-7262 In reply to ThomasLaRock.

I’ll have to add it to my pile of blog posts in waiting. The problem you run into with that particular query is this:

Is using contracts between layers of an application a best practice? Undeniably yes! There are tons of source material on this.

Are stored procedures and views considered a proper contract? Depends on who you ask. There’s so much vitriol in the stored procedures vs ORM debate in particular that I doubt you’ll ever find anything resembling an accepted best practice in the same vein as layered architecture.

]]>
By: ThomasLaRock https://thomaslarock.com/2012/08/database-refactoring/#comment-7251 Mon, 13 Aug 2012 13:28:00 +0000 http://thomaslarock.com/?p=9134#comment-7251 In reply to Eric Wise.

Eric,

I can recall the days when I would debate the use of sprocs for accessing data versus code in ASP.NET pages. I was told that it was easier to change a database than it was to update code and rebuild the web app. Naturally, they weren’t the ones that needed to “just change the database”.

I’m glad to see that you have found a method for refactoring that works well. I’d like to see more information on the subject, especially some best practices in database design and data access.

]]>
By: Eric Wise https://thomaslarock.com/2012/08/database-refactoring/#comment-7250 Mon, 13 Aug 2012 12:55:00 +0000 http://thomaslarock.com/?p=9134#comment-7250 In reply to ThomasLaRock.

Good question, answer is it’s something that as a developer who gained DBA skills that came to me as an epiphany and I started doing. In OO development we always talk about “coding to interfaces, not implementation” which basically means we try to expose a generic contract for interactions and code against that instead of against hard coded instances so that we can make many types of implementation changes without changing the calling code.
I had an epiphany years back that stored procedures and views were technically interfaces to the underlaying data model, and if from the get-go I denied applications access to the underlaying tables and made them go through the interface layer that I would be free to make changes to that model and as long as my views/sprocs returned the same interface the client code was expecting it would be invisible to the caller. As we would say in “Separation of Concerns” lingo, it’s none of the code’s damn business how the physical data is actually stored.
As with any blanket statement there are certainly times when direct access to tables is required, but I have found the 80/20 rule applies in my experience where 80% of the time it isn’t necessary, and with the bonus to refactoring it makes a lot of sense to go this route.

]]>
By: ThomasLaRock https://thomaslarock.com/2012/08/database-refactoring/#comment-7247 Mon, 13 Aug 2012 01:49:00 +0000 http://thomaslarock.com/?p=9134#comment-7247 In reply to Eric Wise.

Eric,

I can see how that would work well, is it considered a best practice?

]]>
By: Eric Wise https://thomaslarock.com/2012/08/database-refactoring/#comment-7246 Sun, 12 Aug 2012 23:03:00 +0000 http://thomaslarock.com/?p=9134#comment-7246 In reply to ThomasLaRock.

Database refactoring is where views and stored procedures really shine. If at the time of initial creation you have the foresight to deny clients direct access to the underlaying tables you can refactor those tables with impunity, then just use an ‘AS’ modifier to return the new column as the old name.

Pass along some deprecation warnings and then eventually cut them off.

]]>