Re: Database Redesign and Migration

David Cressey wrote:
> "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"?

I'll let 'er know you miss her ;-) happy thanksgiving from kalamazoo mi usa --dawn Received on Thu Nov 23 2006 - 05:05:26 CET