Job98456


 
HomeCalendarFAQSearchRegisterLog in
 

Adopting Database Refactoring Within Your Organization

View previous topic View next topic Go down 
AuthorMessage
raj_mmm9




Age : 45
Joined : 08 Mar 2008
Posts : 1850

PostSubject: Adopting Database Refactoring Within Your Organization   Mon 17 Mar - 14:34

Although the adoption of effective tools is an important part of enabling database refactoring it is only the tip of the iceberg – database refactoring requires a significant cultural change within your organization. Because database refactoring is an enabling technique of the Agile Data method many of the cultural issues for adopting database refactoring are the same ones that you face adopting the Agile Data method in general. These cultural issues include a serial mindset within many data professionals, resistance to change, and political inertia. The following approach should help you to overcome these challenges:

Start simple. Database refactoring is easiest in greenfield environments where a new application accesses a new database, and the next easiest situation is when a single application accesses a legacy database. Both of these scenarios are typified by Figure 1. By starting simple you provide yourself with an environment in which you can learn the basics, once you understand the basics you are in a much better position to tackle the situations typified by Figure 2.

Accept that iterative and incremental development is the norm. Modern software development methodologies take an iterative and incremental approach to software development. Although serial development is often the preferred approach by many data professionals unfortunately it doesn’t reflect the current way that application developers work. Time to change.

Accept that there is no magic solution to get you out of your existing mess.

Adopt a 100% regression testing policy. For database refactoring to work, and in general for iteratively and incremental development to work, you need to be effective at regression testing. To be successful at database refactoring you need to not only be able to regression test the database itself but any application that is coupled to your database. The implication is that you require regression test suites for every single application, something you very likely do not have. So start writing them.

Try it.

Database refactoring works in practice, it isn’t simply just another academic theory. For the vast majority of organizations this is a new, “bleeding edge” technique.


Database Refactoring Best Practices
Fowler (1999) suggests a collection of best practices for code refactoring, practices that I recast below for database refactoring:

Refactor to ease additions to your schema.

Ensure the test suite is in place.

Take small steps.

Program for people.

Don’t publish data models prematurely.

The need to document reflects a need to refactor.

Test frequently.



Database Refactoring in the Real World
Database refactoring supports an incremental approach to the evolution of your database schema, one of the three fundamental strategies (you can give up, take a "big bang release" approach, take an incremental approach). Each strategy has its unique strengths and weaknesses. I suspect that many organizations, perhaps because of a serial mindset, have either tried the big-bang release approach or have been too scared to do so and have now given up. It doesn’t have to be this way. Yes, it will likely take a significant effort for your organization to put the culture and technologies in place to support database refactoring across your enterprise, but in the long run this is likely far more palatable than your other alternatives.

See the Catalog of Database Refactorings.

Regardless of your strategy database evolution is hard, something that is particularly true when your database is highly coupled to other things. Database refactoring is not a silver bullet that’s going to magically solve all of your database problems. This article described how to successfully approach database refactoring within a simple, stovepipe environment.


Suggested Resources
Agile/Evolutionary Data Modeling
Agile Database Best Practices
Catalog of Database Refactorings
The Criteria for Determining Whether a Team is Agile
Current State of Data Management: July 2006 Survey Results
Database Refactoring: Evolutionary Database Design (Part 1 and Part 2) Pearson Education
Database Refactoring Smells
Database Regression Testing
On Relational Theory
Questioning Traditional Data Management
Refactoring Databases (Objectview Issue #10, 3.4 Meg PDF)
The Rename Column Database Refactoring: A Complete Example
Ruby on Rails -- Active Record Migration
Visual Studio Team Edition for Database Professionals
Whence Data Management? explores the current state of database management, including database refactoring
Whence Data Quality? explores the current state of data quality
www.databaserefactoring.com
This book describes the philosophies and skills required for developers and database administrators to work together effectively on project teams following evolutionary software processes such as Extreme Programming (XP), the Rational Unified Process (RUP), the Agile Unified Process (AUP), Feature Driven Development (FDD), Dynamic System Development Method (DSDM), or The Enterprise Unified Process (EUP). In March 2004 it won a Jolt Productivity award.
This book describes, in detail, how to refactor a database schema to improve its design. The first section of the book overviews the fundamentals evolutionary database techniques in general and of database refactoring in detail. More importantly it presents strategies for implementing and deploying database refactorings, in the context of both "simple" single application databases and in "complex" multi-application databases. The second section, the majority of the book, is a database refactoring reference catalog. It describes over 60 database refactorings, presenting data models overviewing each refactoring and the code to implement it.



Working Effectively With Legacy Code describes techniques for refactoring and testing existing, legacy code. Few teams have the luxury of building everything from scratch, instead they must work from an existing base of code, or minimally integrate with other legacy systems. In this book Michael Feathers covers the fundamental techniques which agile developers need to effectively work in these sorts of environments. You don’t need to stop all development and rework your legacy code, instead you can ease into it over time, and this book shows you how to do that successfully.
This book presents a full-lifecycle, agile model driven development (AMDD) approach to software development. It is one of the few books which covers both object-oriented and data-oriented development in a comprehensive and coherent manner. Techniques the book covers include Agile Modeling (AM), Full Lifecycle Object-Oriented Testing (FLOOT), over 30 modeling techniques, agile database techniques, refactoring, and test driven development (TDD). If you want to gain the skills required to build mission-critical applications in an agile manner, this is the book for you.




Back to top Go down

Adopting Database Refactoring Within Your Organization

View previous topic View next topic Back to top 
Page 1 of 1

Permissions of this forum:You cannot reply to topics in this forum
Job98456 :: Databases-