walker@amdcad.AMD.COM (Paul Walker) (01/24/89)
I have seen several articles related to RDB design, the pros/cons
of the relational choice, references on RDB design, and criteria for evaluating
a relational database. Each and everyone has beckoned me to respond but I have
not for several reasons... Now is the time to provide my input on matters
in these areas.
1) RDB design
There are two basic schools of thought. These are the "Entity-
Relationship model" and the "Normalization from functional dependency model".
If you think the names are confusing, try actually following a strict
model definition in todays industry!!! In my case that industry is
semi-conductor manufacturing; specifically CAM, SIM, SPC-- using
both relational and hierarchical databases. How are they designed ?
I must respond by saying "an understanding of general data structures will
will take you a long way in this understanding." Secondly, why would you
want to design one anyway? That is, understanding a RDB does not mean you
need understand all details of it's design...follow? (I mean no offense to
those PHD candidates who are trying to actually design one) What you need to
understand is the concept of relations and their relation to other relations...
2) Why the RDB choice
Well, this seems obvious, but the choice relates to your actual
needs. I personally can not imagine using anything else! In our case we have
over 50 databases and most of these have over a million records per table
with several tables per database. Therefore in our case the relational model
was the only choice.
Additionally, we needed TRUE distributed functionality. There was
only one vendor that offered this. (There were several that claimed
to offer distributed functionality but only one that did) To validate
my statement consider this... DEC has negotiated a contract with this company
to to offer their front-end tools and distributed functions as part of their
product set.
3) RDB evaluation
We too have gone through an extensive db evaluation. This took several
months of benchmarks and negotiations. However, the bottom line is.... Your
db choice is what ever meets YOUR needs. Different mfg's have products
keyed to different needs. That is, why would you pick a vendor who claims
a great transaction processing algorithm when what you need is an intelligent
query optimizer? (ie. a banking db will not work in the semi-conductor industry.)
All in all, performance is a wash between most vendors. Therefore, it is
functionality, ease of maintenance, and application tools that should drive
your decision.
I am very satisfied with our decision and willing to discuss our
choice or any of the above subjects in detail with anyone that is interested.
I went through hell for several months asking all the questions. When the
smoke cleared, it was no longer an academic question - it was a functional
question.
Paul Walker
Advanced Micro Devices
walker@amdcad.amd.com
(512) 462-5874