Taking Over Someone Else's Database

[mcucino]

Hi All, this is a very general question but I'd love to get some input. Recently I've had a few projects assigned to me that involve delving into a database designed by someone else and trying to find and troubleshoot the errors and make improvements. The initial assignment is listed as "gain an intimate understanding of the workings of the database." These databases have hundreds of objects and hundred of pages of codes to go through.

1. Does anyone have any tips for how to gain a quick understanding of a new-to-you database?
2. Is there some sort of mystical magical map that would show me how everything works without clicking on every object and looking for dependencies or viewing database documenter files for every object?

Any ideas would be greatly appreciated.

[orange]

Is that someone else still in the organization? That would be the first place I'd look.
What is your background with
a) the organization and its business practices --systems support, documentation, etc?
b) the databases in question
c) database design, operations and maintenance generally?

There is a series of business analysis knowledge nuggets by BA_Experts on youtube. They are very factual, practical and humorous. I think you will get some ideas by watching a few of those.

Good luck

[mcucino]

Thanks for the input, I will definitely check that out.
a) There are currently three organizations I am working with on separate projects and none of them have any idea how the database works. The developers essentially abandoned them with the product so I have very little information or resources aside from the code in the database itself.
b) all of them are brand new to me!
c) it's generally just maintenance and fixing small bugs but ideally suggesting and implementing design improvements

I am honestly wondering on some of these projects if I'd be better off starting from scratch! It seems like it should be easy and I'd like to think these other developers just way over-complicated it, but that's probably wishful thinking.

[CJ_London]

just some general comments

it's generally just maintenance and fixing small bugs but ideally suggesting and implementing design improvements

take your time. Make sure you fully understand what is going on and if not already done, document the code with notes about what the code is doing. Think of the notes as telling a story - in much the same way an initial brief should have been written, but almost certainly was not. I would hazard a guess that 90% of access databases have not been well written - when I go back to look at stuff I did a long time ago, I cringe. And stuff I write now I expect I will look back on and think dohhh!. Take this view - if it works, it works, don't mess with it.

Also be clear about what a bug is. To me a bug is where something is not 'doing it right' which may or may not be generating an error message. A bug is not 'not doing what I expected'. Many years ago I wrote something which was passed by the client and everyone went away happy. A few years later I was called back to provide some additional functionality, and whilst doing so I noticed an error was coming up when a particular form was opened - click OK and everything was fine. For all those years, the users had accepted this as normal behaviour and never once queried it with me.

When you do fix/improve something, make sure you have plenty of backups and keep a comprehensive log of all the changes you have made. It is a pain, but with the law of unintended consequences, one mans bug is another mans salvation. You can end up fixing one and starving the other.

[orange]

I agree fully with ajax's comments/advice.
I find this comment by you a little confusing

The developers essentially abandoned them with the product

If the developers were contracted/hired to develop something, they had to be given some sort of specification/requirement document. So that should be somewhere within your organization and that would be helpful.
Don't start be adjusting a physical database -- get a clear (or at least a comprehensible) statement of the proposed database/application. Use that as your base and add to it as information is discovered. Get users/managers involved to review and agree/comment/accept as you move along.

You may get some ideas from this post