Tom van Stiphout <no*************@cox.net> wrote in
news:3e********************************@4ax.com:
If they are "a complete mess", then the db designs probably aren't
very good either. Typically you would want to start with analyzing
the business needs, and then design a database that meets those
needs. At some point you'll write a conversion program that moves
the data from the old databases into the new one.
But I wouldn't discard the old database front ends, or ignore them
during this project. They will be good clues as to what the people
who created them were trying to accomplish. If you throw them out or
ignore them entirely, you're losing all that information and will
have to collect it again from users who may not be able to
articulate their needs sufficiently to allow you to get the whole
picture.
I've replaced many failed applications, and started over with
entirely new code (and highly recommend completely redesigning the
data schema, was well, and never just using an existing schema --
every time I've used the old one, it's ended up being a huge mistake
that limits the capabilities of the app built on top of it), but I
always study the existing app very carefully to see what kinds of
tasks were implemented and what information was included and so
forth. It may be badly done, it may have lots of errors and mistakes
and look really ugly, but it's still going to tell you a lot about
what somebody somewhere along the line considered important enough
to attempt to implement.
--
David W. Fenton
http://www.dfenton.com/
usenet at dfenton dot com
http://www.dfenton.com/DFA/ 
