Refactoring Databases? Too late!

[Jason Liao]

I'd like to have this book for free, but refactoring database seems too late for SDLC or a project. If the project finished or applications running well,my opinion is that it is the last step to change database schema and keep away from it as possible as you can.

Your comments are welcome.

Thanks.

[Ilja Preuss]

You are right that refactoring doesn't make sense if you know that you will never again have to touch the system.

But as long as a system is used, there are needs to change it. If you don't make refactoring part of your daily work, those changes will become harder and harder to do.

[Adeel Ansari]

Moreover, agility is a well recognized term in software project.

[Gian Franco]

Jason,

I agree that you shouldn't touch the
database if everything is working fine.

Alternatively if some changes are
needed to accomodate new insights,
or solve a problem, I guess that
looking at the list of refactorings
might bring you to ideas you would
probably not consider at first.

It would be interesting though to
see some statistics that compare
the use/need of code refactorings
vs database refactorings, since the
database is in practice a static
element in the whole picture on
which the intrisically dynamic code
operates.

Gian
[ July 27, 2006: Message edited by: Gian Franco Casula ]

[manuel aldana]

when i remember from books and articles that 60% of the costs are bound to maintenance, refactoring practices (and the whole project organization around it: build management, unit tests etc.) are a very valuable (but often undermined) thing.

in some cases (e.g. shorter life-cycle software) 60% is maybe too high, but i think it is very rare that after software-system delivery your team is never going to touch the code again.

[Scott Ambler]

I recently ran a survey for Dr. Dobb's Journal (www.ddj.com) regarding the current state of data management. The results will appear in the November issue, which will be available online for free, and I can't reveal the exact numbers here. The short story is that the current state is really, really bad. Traditional data professionals have pretty much given up and don't have any sort of coherent, viable strategy for evolving and/or fixing their database schemas, even though the vast majority admit that data is a considered to be a corporate asset (no surprise there) and that their production databases have design and/or quality problems. They're really lucky that people expectations of them are very low, something that has clearly come out of the survey, otherwise I doubt that they'd keep their jobs.

- Scott