By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,479 Members | 1,603 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,479 IT Pros & Developers. It's quick & easy.

Reorganize Databases

P: n/a
I have just inherited several (20) MS databases that are a complete
mess. The person that developed these databases had no database
development background and no documentation for any of her databases.

I'm thinking about deleting everything but the tables, but I'm not
sure if this is what I should do. Several of the databases have the
same information just in a different format. I would like to get them
organized together and in one directory location to have more of a flow
to the work process. Basically, what I'm asking is how can I get a
flow process going and not lose any of the data?

Feb 24 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
On 24 Feb 2006 13:20:54 -0800, "IT_8003" <le*******@hotmail.com>
wrote:

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.

-Tom.
I have just inherited several (20) MS databases that are a complete
mess. The person that developed these databases had no database
development background and no documentation for any of her databases.

I'm thinking about deleting everything but the tables, but I'm not
sure if this is what I should do. Several of the databases have the
same information just in a different format. I would like to get them
organized together and in one directory location to have more of a flow
to the work process. Basically, what I'm asking is how can I get a
flow process going and not lose any of the data?


Feb 25 '06 #2

P: n/a
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/
Feb 25 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.