Re: Database Redesign and Migration

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1164168013.159930.224020_at_f16g2000cwb.googlegroups.com...
> 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.
>

Who are you, and what have you done with our erstwhile friend and gadfly, "dawn the crank"? Received on Wed Nov 22 2006 - 13:43:00 CET