[46] in Athena_Backup_System
Re: Issues raised at the "High-Level Design" review
daemon@ATHENA.MIT.EDU (Diane Delgado)
Mon Dec 5 11:41:52 1994
To: athena-backup@MIT.EDU
In-Reply-To: Your message of "Sat, 03 Dec 1994 07:53:43 EST."
<9412031253.AA13670@imbrium.MIT.EDU>
Date: Mon, 05 Dec 1994 11:41:30 EST
From: Diane Delgado <delgado@MIT.EDU>
>That was in reference to public-domain DBMSs. The preferred
>alternative of the hawks was a set of custom-coded ndbm-based database
>functions. That alternative (the only alternative, really) was not
>described by anyone as garbage.
Thanks for the reminder. How could I forget about that - there was a discussion
which followed the review which lasted at least another hour or so which
dealt with this subject. One of the main reasons
for discarding this approach is that it would require extensive
modification to meet both the robustness requirements which come from the
operations group and the requirements of ease of information retrieval which
is also a requirement which comes from the target users of the system.
These requirements are two of the significant things which make
the difference between the AFS-supplied backup and what we are doing.
Coupling these with the fact that the system won't do us any good if
it takes several years to complete, the preference is to use a
database which requires the least amount of modification and meets
both of these requirements, hence the choice for a off-the shelf
"product" dbms. If one compares the time it would take to fixup
dbm to meet the requirements, with the prices which we've been
quoted for academic licences, one can't justify spending any
development time on enhancing dbm. Yes, for some a project such
as enhancing dbm to meet these requirements might be interesting,
but it would probably at least double the development and testing time and
still wouldn't be as good as something like Oracle. But anyway,
our goal is to produce a backup system which meets our needs, not
design yet another dbms that we must maintain ourselves and
which will probably become obsolete in a few years.
When presented with these points, the only argument I received
from the "hawk" side was that "we can do it ourselves" and
concern to vendor response with respect to problem reports.
The former point isn't a valid argument, and
the latter can be dealt with by those who write up the contracts;
and certainly vendor response can't be worse than our internal
support, where it's so often pointed out that we don't have time
to fix bugs. Given that, I certainly wouldn't want to burden
our group with having to support yet another technology
(the suped-up dbm).
One question does come to mind, though, in order to avoid
disatisfaction with the support issues, we should ask ourselves
what we expect with respect to support and are our expectations
reasonable? It's possible that in some areas, we are holding
the dbms vendor to higher standards than the standards we have for
any of our other vendors or even our own internal support.
I do agree that we should perform the robustness demo, prior
to the design review (provided that we have a dbms by then)
so that we have proof for all that this will, indeed, work.
