how do I determine when to keep or when to replace a legacy database structure?
and once I determine that, what do I base my decision on?
how do I compare and contrast a relational to an object-orinted database.

Hello Fahd,

Let me answer each question in turn.
Q1. How do I determine when to keep or when to replace a legacy database structure?
A1: The short answer - When it isn't needed any more or fails to perform
the required tasks. The longer answer would get into the value equation;
Is the cost of using this tool more or less than the value to your
organization? If the answer is that it costs more OR it can be replaced
with a far less expensive replacement - then it is time for change.

Q2: Once I determine that, what do I base my decision on?
A2: In a business, I would look at rate of return [value > investment],
net present value [benefit - costs taking into account cost of money], or
reduction of cycle time [do the same job faster]. I suggest you ask
another person at your organization what has "sold" replacement jobs
in the past.

Q3: How do I compare and contrast a relational to an object-orinted database?
A3: This is perhaps the easiest question to answer. Perhaps the simplest
explanation is to refer to a relational database as a set of tables with
external code (queries, reports, etc.), and an object oriented database as
a set of objects (encapsulated data with code). A more complete answer can
be found at sites such as:
  http://www.tietovayla.fi/borland/cplus/revquide/oo1_rel.htm
  http://www.odbmsfacts.com/articles/object-oriented_databases.html
  http://www.btinternet.com/~xmldatabases/ot97/ot97.html
You can find more examples by searching with the phrase
  comparison of object oriented and relational databases

  --Maniac

Thank you for the feed back.