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.
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.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
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 ]
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.
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.