How to pick a DBMS

How to pick a DBMS

Post by rid.. » Sun, 02 Sep 1990 19:06:00

My boss has just informed me that I am on a committee which is supposed to
select a DBMS for use in all of our hospitals around the country.  Since I
will have a lot of learning to do if I am going to help make an intelligent
decision, I thought I would start by asking for some advice.  I am interested
in the following:

(1)  In general, how would you go about evaluating a DBMS?  Is there a good
published guide to the subject?

(2)  What do you think about the following criteria which have been handed to
the committee by higher-ups?  (I confess that I don't even know what all the
buzzwords mean!  Yet.)

    -- Common data dictionary.  Provides standardization of language and data
       elements.  Must be flexible and have ability to be changed.

    -- Query language / ad hoc report writer / statistics / forms

    -- Prototyping

    -- Fourth generation language.
       -- cross multiple mainframes
       -- program generator
       -- development processing
       -- linkage to lower level languages
       -- compiler (hardware specific)
       -- interface out/in with standard file techniques for file transfer
          (e.g. Lotus, dBase II/III/+, R Base V, Informix, SQL, etc.)

    -- Total compatibility across hardware.  [They don't say this, but they
       want it to at least work in Vax/VMS and Unix System V environments.]

    -- Friendly/flexible user input interface (MacIntosh type)

    -- Graphics/images/animation as a data element

    -- Full network support / distributed processing

    -- Fast < 3 second screen-to-screen response

    -- Security levels (to be data element level)

    -- Shadowing capabilities

    -- Interface with statistical package

(3)  What are the pros and cons of the following candidates?

        Focus           IBM-SQL         IDS-2           Informix
        Ingres          Mantis          Nomad           Oracle

As usual, please post responses of widespread general interest to the net;
please send more specific comments directly to me and I will summarize.
Thank you.

--- Prentiss Riddle ("Aprendiz de todo, maestro de nada.")
--- Opinions expressed are not necessarily those of Shriners Burns Institute.


How to pick a DBMS

Post by m.. » Sun, 02 Sep 1990 23:52:00

DBMS evaluation is both a MANAGEMENT and a TECHNICAL subject.  One must
know about the applications and/or range of applications being considered,
the programming talent available to the organization, prior experience
of the development group, nature of the applications (DP vs. MIS/DS or
hybrid's, etc.).  There is much to consider.  An excellent starting
reference in my book is James Martin's "Managing the Data Base
Environment" Prentice-Hall 1983.  I am doing a workshop on this
very subject in Feb. in S.F., and have some 20 pages of notes so
far I would be glad to discuss if you desire.  Sometimes the mail
link between the well and the outside is not the most reliable, but
I will try if I can help!


1. Picking correct DBMS

I've started researching the whole matter of choosing a database
server for my company, and the scope of this investigation is

At this company, there is already a strong pro-MicroSoft
predisposition; they want to use NT SQL Server. A PB consultant has
shown up, telling them that NT SQL/Server will do everything they

I have reason to be circumspect: within a year, they will be faced
with processing 3 million _NEW_ call detail records (they are a
nascent long-distance reselling phone company) PER DAY, but sending
out _MONTHLY_ bills to roughly 100 different customers (other phone
companies) -- easily 5 billing cycles per month.

I think you can see why I am concerned about commiting them to a MSFT
course of action.

The basis of my concerns are 2-fold: performance & portability:

Since they are going to have _LARGE_ transactional requirements within
a year or two, I am worried that MSFT SQL Server WON'T be able to take
the pounding. Sure, a Quad-Pentium SMP NT box is cool, but can NT
actually get the job done? My suspicion is their req's indicate a
UNIX-based/RISC-based system _NOW_ (an RS6000 or SPARC). I'm not
aware, at least yet, that there is a NT SQL Server for anything other
than Intel.

Since MSFT database server offerings are strictly NT or Novell; there
are no other OS platforms to migrate to. I understand NT runs on Alpha
& MIPs and that SMP provides an awesome boost in power, but I'm
concerned that even with MIPs or Alpha hardware, NT won't provide the
requisite power they'll need in 2 years. By then they couold be faced
with the transition cost of migrating away from NT SQL Server to the
nearest relative, Sybase - or worse, a massive re-write over to
Oracle. Perhaps this transition from SQL Server to Sybase used to be
easy, but Sybase & MSFT are going off in different directions these

Any comments?


Then there's the whole issue of data wharehousing....
First of all, there's an existing Xbase culture (FoxPro) that's
well-developed, but unhappy with the requirements of Visual FoxPro,
hence, they're leaning towards Vis. dBase 5.5 / Delphi. They are
accustomed to working stand-alone and taking care of themselves,
hence, I'd like to give them an easy-to-use inexpensive database
server for the wharehousing (mostly aggregates and lookup tables).

I've looked at MSFT SQL Server, WatcomSQL (now Sybase SQL Anywhere) &
Borland's Interbase (The aforementioned PB consultant told me it
crashes 4 times more often than MSFT SQL Server). Any comments?



2. active database overview?

3. Error accessing CSV datasource with DSN-less connection string

4. PICK dbms/os on UNIX

5. Move Data between tables

6. The Pick dbms

7. 16bit version of Pdox7

8. DBMS 26 or DBMS 27 error

9. Web fronted DBMS vs. DBMS backed web

10. ADO thinks DBMS is done, but DBMS ain't done

11. Please recommand some newsgroups about spatial dbms and spatiotemporal dbms

12. To DBMS or not to DBMS