Re: Database Redesign and Migration

kramer31 wrote:
> Hi. I apologize if this post is off topic but it doesn't relate to any
> particular database, so I'm posting here.
>
> I've come to work for a new (very small) company as an application
> developer. The legacy code that is here is rather poorly written and
> the database which provides the infrastructure is rather poorly
> designed.
>
> Now the database is not really that complicated, so I think that can
> redesign it in a better way (new tables to store data rather than limit
> numbers of fields where there should not be limits, better naming
> conventions, etc.).

It is typically the case that a database design can be improved. It is often the case that a new set of eyes will have different opinions than a previous set regarding naming conventions and design choices. Some designs are obviously bad by everyone's standards. I would advise that you not refactor a production database simply for the sake of making it a better design, without any new requirements. Identify new requirements -- what does the database + all related software need to do in the next round of changes (NOT in all possible changes ever), and then refactor your database along with code in light of those requirements.

> The problem is that redesigning will require a code re-write and will
> require our users to update and for us to do something to migrate their
> data.

When you identify the requirements for your next project (phase), include the quality requirement that the project must include procedures for migrating existing databases as needed.

> We are sort of looking at two options:
>
> 1) We can redesign the database all at once and slog through the
> re-write and migration or

If you redesign in light of your new requirements, you will address those aspects of your current design that are relevant to your requirements. This would rarely be all of the database design.

> 2) We can redesign it a table or two at a time

Do not approach it by table, but by requirement. If there is a new requirement to have the software include the xyz feature and this feature includes software components a,b,c and tables s,t,u,v then redesign those components, refactoring existing code and adding to it as needed.

> It seems that 1) should allow us more flexibility in design. I've read
> a couple of texts that strongly suggest redesigning from scratch

That approach is largely out of favor by those who consider themselves in the profession of "software development" while those who more narrowly define their profession related strictly to the database are more likely to think you should do one mega redsign.

> rather
> than making changes to the old database structure, but 2) should make
> the code rewrite easier.
>
> I'm also not very familiar with data migration. Can anyone recommend a
> reference on that?

Don't know references, but there should be plenty of examples and experts out there. Best wishes. --dawn

> Thanks.
Received on Wed Nov 22 2006 - 05:00:13 CET