summary of replies to request for info on UNIX databases
Beverly Dyer
bev at hlexa.UUCP
Tue Jul 3 06:51:33 AEST 1984
This is a summary of replies to the article I posted a couple of
weeks ago, requesting information on UNIX databases.
My article listed problems with POLARIS/URSA and a wishlist
for our ideal DBMS. This summary may not read perfectly, it was
intended to provide all the useful information... I haven't
rewritten most replies.
Beverly Dyer
*******************************************************************
RTI INGRES
*****************************************************************
You may find that RTI INGRES ( a comercial product ) has almost
all of what you want. We benchmarked it against Berkley INGRES
and it was twice as fast on a sort, slightly slower on a replace
and 60 times faster on my particular query. INGRES doesn't allow
heap updates to isamed relations, but RTI does provide a nice
report generator.
Their documentation is as good as any I've ever seen, and their
support has also been excellent.
ingres and polaris are from the same molds and suffer some of
the same problems (no nested database calls, performance can
be quite poor, etc.)
as far as your wishlist goes:
wrt ingres -
+ fast - depends - we could talk about this for hours. in many cases
it is no faster than polaris, in some cases (complex queries,
in particuar) it is much faster. a lot of performance improvement
can be obtained by proper tuning.
+ supported - by the time you receive this at&t ingres should be an
announced product of at&t information systems. this means that
come august when general availability occurs there will be
hotline support as well as a group of labs folks devoted to
maintaining - enhancing, etc. (not to mention work being
done by the vendor (relational technology in berkeley californis))
+ robust - flexible - easy to use - hard to say - i find it to be all of
these. however, i can come up with reports or applications i want
to build that would be difficult to generate with ingres tools.
+ no size limits - as you mention, ulimit, is a limit in itself - ingres
does use the unix file system so it too is subject to ulimit
constraints. other than that the following constraints hold:
maximum tuple size - 1K
maximum # fields per tuple - 128
maximum characters per field - 255
no limit on relation size, database size, # of
relations, etc. other than ulimit and
the fact that a single database must reside
on a single device which translates to a
single file system for unix
+ security - the permission structure is quite nice (particularly compared
to polaris) permissions are done at three levels:
+ global - each user must be given permission to use
the ingres system
+ database - a database can be created public or private
if public, any valid ingres user may get into
the database, create relations, and look at
relations (if they are so authorized - see next
item) within the database
if private, the dba must explicitly name the users
that may access the database, an authorized user
must have further authorization to access or modify
particular data (see next item)
+ data - the dba for a database may use the define permit
command to specify access permissions for shared
data in the database. these permissions are of the
form
define permit OPERATION
on RELATION (FIELD LIST)
to USER|ALL
on DAY-OF-WEEK
from TIME-OF-DAY to TIME-OF-DAY
on TERMINAL_NAME
where QUALIFICATION
[my syntax may be a little of but you get the picture]
+ option for virtually concurrent access - not sure what you mean
+ ability to reformat tables - unfortunately this is not as
straightforward as it should be - you must make several
steps.
+ efficient keyed and indexed access - ingres supports ISAM, HASH,
and HEAP access methods - a user may further request compression
(this only removes excessive blanks) - fillfactors (what percent
of a page should be filled (a certain amount is usually left
free for subsequent insertions) - min and max primary pages
+ regular expression searching - supports * ? []
+ backup procedures for system failures during appends - not quite
sure what you're driving at - but ingres has optional backup
and recovery procedures that would cover this.
+ data translation - yes
+ useful report generation - yes - no graphics just yet
c interface:
+ ad hoc/ dynamic queries - yes
+ good (trappable) error codes - yes
+ use of database calls as library functions - no
+ nested and recursive database calls - no
+ good i/o reading/writing to/from structures - no, if you mean can
i define a c structure that is equivalent to my tuple definition
and then say cstruct=tuple
+ get next function - not quite sure what you mean here.
interactive interface:
+ consistent command syntax - pretty good, although there are a few
discrepancies
+ good error messages - relatively speaking, yes
you did not mention the forms interfaces.
the forms editor and equel/c forms interface are both very nice.
report-by-forms and query-by-forms for quick report building
and data access, respectively, are both very useful.
we at Ballistic Research Laboratory have been using RTI INGRES for about two
months now, and we LOVE IT. VERY easy to use, modify, design screens and
applications. We have not done anything with the "C" interface yet. We are
not currently in a heavy production environment with it yet, but we are
pleased with the response times we are getting (no it is not subsecond but I
have not seen any yet running under UNIX with large volumes of data that are
fast). Our support for the few problems we have encountered has been
EXCELLENT. Syntax is not exacting but pretty much freeform, very easy to
use - we had a class for non-computer clerical types and they picked it up
right away and were confident in creating their own data bases and queries and
forms and reports - all in just 3 half day sessions!!!! Security is by
database, field, value in field, time, person, terminal , ...etc. Redesign is
minimal effort with the utilities provided to unload and reload the data base.
They use "page level" locking only for the duration of the update
(disadvantage is the entire page is locked and not just the record for the
update). The journaling and checkpoint facility for backup and recovery
looks excellent (we are just beginning to use this feature).
I am in the process of finishing up a comparison of Unify and RTI
Ingres. You don't say what size machine you are running, but assuming it
is Vax class, I would recommend Ingres. It is a much more versatile and
usefule system. I think it matches all of your wishlist, except for a few
points, and those are under development. Our support from RTI has been superb,
a rare thing these days.
If you are running on a smaller machine (Callan, Tower, Onyx, etc), then
look a little more carefully at Unify. It will not match all of your wishlist,
but it is smaller, and more efficient on smaller machines. It is much less
friendly and versatile.
******************************************************
UNIFY
********************************************************
Have you inquired about or used UNIFY from North American
Technologies? I don't which machines it has been ported to, though
(we use it on an ONYX C8002M).
UNIFY is fast (average 2 disk reads per record request) and
relational. I have heard that support is OK; I haven't had a need
to deal with NAT, though.
As to your wishlist:
no size limit - database may either be a regular Unix file
or may be a mounted volume (faster, since
it bypasses Unix I/O buffering)
security - uses its own user file; each user may be limited
to which screens and/or programs are available
(database and record); also each field in each
record may have a password associated with it
concurrent access - locking is used only during update (i.e.
no individual record may be accessed while
in use at another terminal)
reformatting - fields and/or records may be added at any time
by reconfiguring the database; record keys are
an exception - records containing data must be
deleted before changing keys or removing record
type
key access - has both hashed key and indexed
btree access methods
searching - in the 'query by forms' mode, searching may be
done by using the meta characters '*', for matching
any number of characters, and '?', for any individual
positional character
for numeric searching, the relational operators '>',
'<', and '!' may be used
backup - comes with database backup programs (writing out and
reading in (to/from tape on our machine))
data translation - depends on how fields are declared during
setup; output to devices (terminals, files,
etc.) is formatted automagically; data is
stored in its most convenient form - chars
as bytes, integers as shorts or longs, and
floating as longs; integers as short or long
is machine dependant
report generation - weakest point;no graphics capability;rather
inflexible format (some versions have the
RPT report generator which is more flexible
than the LST report generator); also, queries
and reports may be generated by using the
SQL query language (a subset of IBM's SEQUEL)
host language interface - has interfaces for COBOL and C; the C
database library is quite extensive;
errors may be handled in any manner
desired; combinational fields are
treated as structures and must be
declared as such in C programs accessing
these fields
UNIFY has a screen formatter for design of data entry/query
CRT screens. Data entry/query may be done with either the 'canned'
program or by user written host language programs. The database may
be accessed by programs outside of the UNIFY program by using the
database library (C or COBOL). Programs using UNIFY include files
must be preprocessed by UNIFY's preprocessor 'ucc' (at least this is
true for our machine; other machines may not have to). Any programs
accessing the database, including UNIFY itself, may be run setuid and
permissions on the database set accordingly.
One of the programs is a hash table statistics generator. It
gives vital statistics on the database such as percent of table in use.
I'm pretty sure UNIFY is available for PDP's and VAXen and a few
of the micros running Unix. I am not sure about other machines. I'm
afraid I haven't been very clear on the user interface to UNIFY, but
there are several prepackaged programs which allow data entry/query
depending on what you want to do.
If you have any questions about UNIFY, feel free to ask. I'm
not a 'wizard', but I should be able to answer most of your questions
(except price! - our version retails for ~$3,000).
*************************************************************************
ODIN
*************************************************************************
Problems:
No nested lists.
Arbitrary size limits. (datafile, # of screen images per form, etc.)
Very slow query.
NO C interface.
Poor support.
Poor training.
Good points:
Execellent data integrity checking.
Full screen mask editor.
You can bring up an online application *REAL* fast.
NO codeing necessary.
*********************************************************************
(one good comment about MISTRESS)
****************************************************************
Take a look at INFORMIX from Relational DataBase Systems ,Inc. We are
reasonably please with its performance under Unix System V on a BBN C-70
computer.
*****************************************************************
Have you checked out Appgen. I'm going to soon. AT&T is appearently
working a deal with the developers (Software Express of Houston TX) .
More information about the Comp.unix
mailing list