Janet Lee <JLEE@SUMEX-AIM.ARPA> (02/08/85)
The following are some of the responses I recieved to my query about
commercially available relational database systems for UNIX System 5.
Thanks again to everyone who responded.
Janet
I would recommend very highly against Oracle. I did some consulting for
a company that had Oracle on a VMS system. The system was buggy, ran
slowly and the documentation did not match the running system. The
support staff was very unhelpful, at times even rude with the answering
of questions. The salesman was also very difficult to deal with.
While the technical difficulties may very well be solved (my experience
was about 6 months ago), the support problems and the documentation
speak of lack of attention to detail, and general sloppy work. Unless
there has been a major change in personel, I wouldn't chose Oracle.
-----------------------------------------------------------------------------
I have had some experience withthe last three. Which one you
want will depend on what you are doing. For my personal use I would
take MISTRESS, but UNIFY is good for some kinds of well-defined applications,
it is also very well optimized, if you dedicate a whole disk partition
to it.
------------------------------------------------------------------------------
After a couple or three consulting jobs with people who want
relational databases under unix, the concensus seems to be
that unify is the winner. It is without doubt the fastest,
as it is the only one that avoids the unix file system
altogether, just using physio. It seems to do what people
want, and it works (NB I am not a database type). It will
run on all unixes that I know of, and they seem to be pretty
reasonable about putting it up on different processors.
--------------------------------------------------------------------------
You should also consider the Troll/USE relational DBMS and its related
set of tools, particularly if you are doing program development and
information systems work, as opposed to end user queries.
Troll/USE is MUCH smaller and faster than INGRES and Oracle.
There is both an academic (unsupported) and commercial (supported)
version of the software. The commercial version includes a free
trial evaluation period too.
There exist System V ports of Troll/USE, but it hasn't been done
specifically for the MiniFrame. The port should not be difficult,
since the source code includes a little configuration program that
searches the system and then constructs the necessary make files.
----------------------------------------------------------------------------
Having done some consultancy recently, UNIFY seems to be the
favourite. It is certainly the fastest (it doesn't use the
unix file system, just the raw disk) and seems to work
pretty well. I am not a database type, though. It's
available on lots of machines (potentially any) and everyone
I've spoken to seems pretty happy with it.
-----------------------------------------------------------------------------
If you decide to try a heirarchical database instead of a relational one,
please let me know. We sell an implementation of Ansi MUMPS which runs
under (any post-V6) UNIX.
If I knew more about your target plans, I might be able to offer some
information about Informix or Unify... I wrote an interface between
RM COBOL and Informix (also between MicroFocus COBOL and Informix) for
Anheuser Busch. They did a study of Informix and Unify.
-----------------------------------------------------------------------------
THINGS TO CONSIDER IN SELECTING A DBMS:
l. Find out the names of the dbms systems that can be installed on your
present equipment from current product reviews, DATA PRO, and vendors,etc.
2. Match the facilities of each candidate(as well as your existing system)
against the requirements established during the planning phase(i.e. know
what functions your application will require before selecting a dbms,
once purchased you may discover that the dbms does not incorporate or
perform to your application's specifications and may in fact be totally
useless to your organization.
3. Compute the estimated total cost of installation of each system, and
the projected cost savings after the system is installed.
4. Determine the number and skill levels of the people that will be
required to support the system both during implementation and thereafter.
In other words will the casual user be able to design and implement your
application or will you need the services of a programmer. Some
primative dbms' need a lot of user written programs to provide functions not
currently available within the dbms.
5. Get the vendor to give in-house demonstrations geared to both your
DP personnel and your user personnel. Be prepared to ask specific questions.
The more you know about the requirements of your particular application the
more readily you will be able to determine if this dbms meets your require-
ments.
6. Review the documentation of each system for clarity and understanding.
Is it written for the average user or on the programmer level.
If this is a relational dbms, is the reader expected to understand
the concept of a relational dbms or is it explained briefly.
7. Develop evaluation criteria on a specific and detailed level based on
the requirements of your organization's application(s). Attached is
a sample list of criteria.
8. If possible, visit some existing installations and talk to the people
responsible for installing, maintaining, and using the system. Check for
functionality, performance, ease of use, training and vendor support.
9. Once you think you have found the right dbms for your application, try
to lease a copy for some hands on evaluation. It is difficult to make a
thorough and complete evaluation based on vendor documentation, opinions of
other users and answers to your questions.
UNIFY LIMITATIONS(updated)
1. Volume of records cannot be larger than limitation of a UNIX file.
2. Simultaneous users - yes (how many?).
3. Multirecord screens not available.
4. Multiple record joins only possible with sql function.
(SQL is the newly acquired query processor for UNIFY)
5. Multiline fields seem to be limited to 159 chars in the default
form and approx 256 in SFORM.
6. Screen form limited to one page consisting of 18 80 char lines.
7. Query/Report Processor has been combined and renamed Listing Processor.
No changes seem to have been made to this function and one link
reference per record is still a limitation according to my understanding
of this function.
8. Formatted reports are possible with the UNIFY Listing Processor but
are limited. An independent RPT (report processor function is scheduled
for the next release of UNIFY).
9. Data can only be input through screen form at the present time.
UNIFY is working on a DML(data manipulation feature that will allow
the user to insert, modify, and delete data through SQL).
10. There is now a raw data download function in the UNIFY dbms but it
has a bug. It will insert the data into the data base but will not
exit and will hang the terminal and user cannot get back on until
the download process is killed. UNIFY rep said they are working on
it and will send us the fix when its available.
11. Once a data type has been entered for a field (i.e. string, numeric, etc)
that data type cannot be changed unless the entire schema is deleted
and entered again.
12. Documentation states that super user id is limited to 8 chars but system
will only accept 4 chars.
13. When doing a file system check(fsck) on the onyx "Possible file size
error <inode #>" shows up on system containing the unify dbms.
14. If data base is reconfigured after entry of a number of records,
the primary key loses its uniqueness and duplicate records can be
entered. UNIFY manual recommends that the primary key not be
changed as to name, type, etc. but if it must be changed then
executing the Hash Table Maintenance function will correct the
problem of entry of duplicate records.
15. If entry data exceeds 80 chars, some data will remain on the screen
after record has been entered, making it difficult to enter additional
data in that field. Going back to the menu seems to be the
only way to remove this leftover data. This problem has been reported
to UNIFY rep and he is investigating. He suggested that it may be
a problem that involves termcap.
COMMENT: The above problems and limitations still exist on the latest
version of UNIFY which has been significantly improved.
Some new problems with the lastest release(e.g. download
function) may be discovered, if they exist, as Bette attempts
to implement the toolchest dbms.
SOME QUESTION YOU MIGHT WANT TO ASK:
What level of knowledge is required to use this dbms.
What is limit on number of tables,fields,records,data bases? Is limitation
dependent on a combination of factors(e.g combined length of columns and
data fields determines limit on a record)?
Can tables be created by executing a UNIX file?
Once a field is defined in a table can the data type be changed without
rebuilding everything in the data base?
Can a column name be changed once data has been entered into the table/record?
Are there data integrity controls?
Can user shift from one tool to another without an abrupt shift in style,
language, syntax?
RAW DATA DOWNLOAD......
Is there a raw data download tool? How easy is it to use?
Can this tool handle variable length records?
How are errors/problems with the download handled?
How will the user be notified upon successful insertion of downloaded
data or unsuccessful attempts?
Are there any limitations associated with the download tool?
Is there data base security down to the element level?
Are there optimization tools that the average user can utilize to
improve response time, performance, etc.?
SCREEN INTERFACE...
Are multi-record screens possible? Limitation?
Are multi-page screens possible? Limitation?
How are multi-line fields handled?
Can data be pulled onto screen from more than one relation/record and inserted
into another relation/record?
Can data be preinserted/deleted in the screen interface function?
Can data be transferred from one data base to another? How?
Can user specify as many validations on data as he desires? Limits?
Are simultaneous on-line operations possible? How many concurrent users?
Can non-field data be displayed on the screen(i.e. instruction,boxes,titles)?
Is on-line help available for field defines, or data entry?
What types of error messages are displayed?
Is element level security possible?
How easily can form be edited(i.e. insert/delete fields, change attributes,
prompts,etc)?
Can screen be designed and created independently? For instance
can one team member work on designing the screen while another is creating
tables and yet another working with the raw data download or report writer?
Is user told when record has been successfully inserted/deleted from database?
QUERY LANGUAGE INTERFACE....
Are multirecord joins possible? How many?
Can results from ad hoc queries be sent to printer?
How much customizing/formating can be done on data sent to the screen or
does user have no control over how data is formated? (e.g. column headers)
Can canned queries be created and stored as UNIX files?
Can the unsophisticated user learn and use the query language easily?
REPORT WRITER INTERFACE..
Is this tool independent of screen?
Are multi-page reports possible on preprinted forms?
Is language used similar to query language in syntax,style, ease of use?
Are there any limitations associated with this tool?
MISC...
What facilities are there for backup, transaction logging, menu's, security?
How does the INGRES recover from system crashes without loss of data?
What facilities are available for data reorganization?
Is vendor support/training/updates/enhancements provided with purchase of
dbms package?
Graphics support?
Microfiche interface?
In summary UNIFY was not designed for large or complex applications but WAS
designed to run on a 16 bit machine. On the other hand Oracle can handle
large and complex applications but WAS not initially designed to run on a
16 bit machine and has suffered in the adaptation for the PDP-11/70.
If we had to go with UNIFY as an alternative, it would be better than
writing everything from scratch,but let's hope we don't have to. I still think
Oracle is our best bet for getting this project into production given that
we have available a good working version from Oracle Corporation and space
on our equipment to run it.
******************************************************************************
EVALUATION LIST PLUS COMMENTARY COMPARISON BETWEEN ORACLE AND UNIFY
******************************************************************************
DATA BASE FEATURES ORACLE UNIFY
Data Base Organization Relational Relational
Application Languages FORTRAN,COBOL,PL/1, "C",COBOL
Assembler,"C"
Data Base Language SQL(powerful) Query(weak)
Access meth supported Random,sequential, Random,relational
relational
Variable-length segmts yes yes
Data base security yes yes
RECOVERY FEATURES
Checkpoint/restart yes yes
Logging facilities yes yes
OTHER FEATURES
On-line yes yes
Inq/retrieval facility SQL/Screen Form Query by Forms/
Query/Report Processor
Data Entry/ Screen Form(IAP) Limited To SFORM
Manipulation (can address any table running ENTER(can only
that exists, horizontal address one table, if
scrolling to handle more than one table or
multi-line fields, multi-line fields
data can be extracted needed,a "C" program
from one table and entered must be written, data
into another thru the cannot be extracted
screen). Data can also from one table and
be entered,deleted,updated written to another)
etc. with SQL outside screen
form.
Report generator RPT(can print to preprinted Query/Report Processor
forms,page breaks allow one (limited to five lines
RPT program to handle two "C" program needs to
sided forms) be written to handle
larger reports)
Data dictionary support yes yes
Host Language Interface HLI(utility plus user Data manipulation
written code) functions available
written in "C" to be
combined with user
written programs.
Raw Data Load ODL User written "C"
program(s)
Screens IAF(IAG,IAP) SFORM(limited to
(allows multipage one screen page,for
screen applications) multipage applications
SFORM would have to be
written by a programer
Menus no yes
User written menus yes yes
Data Transfer between yes no("C" language
Data Bases program(s) would have
to be written to do
this)
||
PERFORMANCE fair(bad error msgs) (still evaluating)
EASE OF USE difficult to evaluate easy for small applic-
because of the version ations, difficult for
we had. large or complex
applications.
DOCUMENTATION poor adequate
TNG & VENDOR SUPPORT available but poor available
KNOWLEDGE LEVEL OF USER familiar with a crt, directories, basic
(non-programmer) UNIX system(introductory shell cmds,UNIX text
level) editor. Concepts of
storing and retriev-
ing information using
a computer.
Note: Several bugs were discovered during the test and evaluation period
on UNIFY that I assume will be corrected at installation time. Features
where yes appears in both columns means that though features may
differ they are comparable. POC at Uniq for technical questions
was Dennis Meyer.
MISTRESS INFORMIX EVALUATION
Our choice was narrowed down to MISTRESS or INFORMIX. Both were TECHNICALLY
acceptable. We acquired MISTRESS under contract for test. Roy McDonald
has INFORMIX, so we decided to ask Roy to let us test INFORMIX in his
environment which is very similar to our's.
We chose MISTRESS based on several things - among these was the fact
that we could get a partial site license at a very reasonable price
- that we already had MISTRESS installed - that, by the time we finalized
our evaluation, we were familiar with MISTRESS - etc. I'm sure that
some feeling of propriatorship was involved in that we developed several
small systems very successfully during our tests on our equipment.
These are points considered in trying to choose the best Data Base Management
System for our need based on actual use of the Mistress Data Base Management
System and a comparison evaluation between Mistress and Informix.
Points to consider in evaluation of a Data Base Management System.
Informix Mistress
1. Does it have interactive data definition facilities? Slight Yes
2. Multi-user environment? Yes Yes
3. Does it have full screen interface? Yes Yes
4. Can screen files be used for more than one database? No No
5. How difficult is it to make changes to definitions
and data content? Easy Easy
6. Can you manipulate easily file to data base and data
base to file? Fair Yes
7. How good is documentation. Is it easy to follow and
comprehensive? Fair Good
8. Will it run on different types of machinery? Yes Yes
9. Does it have C language interface? Yes Yes
10. Does it have shell interface? Yes Yes
ll. Can it be interfaced with batch processing? Yes* Yes*
12. Is report formatter-writer easy to use? Yes* Yes*
13. Does it have security capabilities? Yes Yes
14. What level security? Item Database
15. Is it easy to dump and reload data base and contents? Yes* Yes*
* These points of interest appear to be more complicated to accomplish
in Informix than Mistress. At this time any loading or reloading in
Informix must be complete record does not handle variable lengths.
Mistress can be selectively by item loaded or reloaded.
The following points are what I consider to be pluses for Informix.
1. Ease of changing data base structures. Informix changes structures
and enters applicable default values(spaces or zeroes) according
to type defined. Also adjusts existing data. Mistress must be
dumped - data and attributes and reloaded after changes are made
to the unix file created when dumped.
2. Informix manual has comprehensive error code definitions in each
section.
3. There are data edit features which can be build into PERFORM screen
formatter.
4. Lookup feature of PERFORM good. Utilizes existing data to derive
current data.
5. Informix locks records rather than tables during an update process.
6. Security permissions may be assigned as low as field level.
7. One screen may contain data from two or more files(tables) which
share multi-field keys.
The following points are what I consider to be minuses for Informix.
1. Building of data base not as easily understood for non-programmers.
Mistress uses prompt method for building which is easily understood
by anyone.
2. Screen format clumsy and cluttered looking, not graphically displayed.
This format ok for programmers but not good for non-programmers.
More user-friendly screen can be built but would be more work for
Data Base Manager.
3. Documentation not as informative or as well organized as Mistress.
4. When loading data base from file must have all fields completely
filled. This is particularly worrisome and error-prone in a large
record.
5. Batch processing more complicated than Mistress. Must be accomplished
via a "C" program process to update selected items of data.
6. Screen process for data entry requires repeatedly indicating through
letters and words which mode you are processing in,i.e.,add, update
delete, etc. whereas Mistress uses function keys and stays in mode
you selected until you exit that mode.
7. Does not have 'empty' feature that Mistress has for a table. Mistress
allows you to empty a table keeping your attribute specification
and inserting new data from that point. Informix dictates that
you must erase total file and reload or rekey your attribute specification.
8. Report formatter-writer is more complex to describe in Informix.
Mistress data elements can be joined in a select statement through
qualifications and/or using a simple 'from' to indicate that data
comes from multiple tables. Informix uses a more complex structure
of reads and joins.
The consensus of our group after discussion and weighing the pros and cons
was that Mistress is a more 'user-friendly' product and will do the job
that we need done.
INGRES EVALUATION
We have been using and developing data bases on it for several months now.
We loved the easy to use forms packages (Query By Forms - Visual Forms
Editor - Application By Forms). The system is very user friendly.
We recently uncovered one very critical design flaw in the current version,
however. The fully functional concurrency control mechanism is NOT AT ALL
what we expected. It is totally unacceptable for a production multiuser
environment. QBF allows a user to retrieve records (or a record) for update -
NO lock is put on these records when they are retrieved for update, thus
another user may retrieve the same record for update and completely negate the
first users updates with no indication that anything has gone wrong. The
natural query language QUEL will supposedly lock pages of data under exacting
conditions which do not include retrieving a single record for update.
Up to the point where we discovered the concurrency control mechanism would
not function as we thought it appropriately should, we were more than pleased
with the product. The end-user business type people found it very easy to
use. The people doing development were pleased with its numerous functions
and very easy to use report-writer feature.
One other problem we discovered was that the QBF function is a very heavy
user of CPU cycles. We have reported this to RTI and they are treating it as
a bug.
We are currently on Release 2.0. Release 3.0, scheduled to be released in
the first quarter of calendar year 85 is supposed to have a record level lock
in QUEL (the natural query language which is not user friendly). QBF which
is what most people would want to do their updates and adds with will still
not have a lock mechanism on its updates (to the best of my understanding).
If you have any other questions please feel free to contact me if you think
I could be of assistance. I certainly wish someone had clued us in on the
lock problem before we got in so deep! We have attended the Ingres Users
Group Meetings and have found that UNIX is the "stepchild" - VMS is the
favored user operating system. Also we found that the majority of data bases
people are using are "personal" data bases. Not too many with large numbers
of multiple users.
-----------------------------------------------------------------------------
>From the databases you mentioned UNIFY is the better DBMS (I don't
know much about MISTRESS). I have done a fairly large application
in UNIFY and although some things were a pain to do they were
much easier than doing them in any other database (especially
informix or ingress). If your DBMS programs are screen oriented
UNIFY provides good utilities for generating default screens and
modifying the screens to suit your test.
I am not trying to plug UNIFY, but after using for about a year (and a few
months) I like it and can do things pretty easy with it.
-------guy@rlgvax.UUCP (Guy Harris) (02/09/85)
> 13. When doing a file system check(fsck) on the onyx "Possible file size > error <inode #>" shows up on system containing the unify dbms. This ain't a bug in UNIFY; it's arguably a bug in "fsck". This error message is printed if the number of blocks implied by the file size doesn't match the actual number of blocks allocated to the file. Unfortunately, if the file has "holes" (i.e., sections in the middle of the file with no blocks allocated to it), these numbers won't agree. "Holes" are a well-known - and even documented - feature (deliberate feature - sparse files can save lots of disk space) of UNIX ever since V6 (although they didn't work as well in V6 as in post-V6 systems - reading a "hole" in V6 caused the blocks to be allocated). I suspect the "correct" answer is to compare the number of blocks implied by the file size with the number of blocks implied by the block number of the highest allocated block (i.e., if the file had no holes, this would be the number of blocks in the file). Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy