bev@hlexa.UUCP (Beverly Dyer) (07/02/84)
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) .