mas@afinitc.UUCP (Mark Savage) (06/06/85)
Some time ago I posted a request for information concerning relational databases for both PC's and UNIX supermicros. I received several responses as well as several requests for the information I receved. Due to the long list of requests I have posted all of my responses as well as the original article. Because I have not had the time to investigate the relational databases more thoroughly I have not made a choice as the one to use. In order to get this information to all requestors I am posting the responses as I received them. Thanks Everyone, Mark Savage ** From the terminal of: Mark Savage <...ihnp4!wucs!afinitc!mas> ** Affinitec, Corp., 2252 Welsch Ind. Ct., St. Louis, MO 63146 (314)569-3450 ============================================================================= > Recently I have found a need for the use of a relational database >on both PC's and UNIX supermicros. I have been particularly looking at >INFORMIX, UNIFY, and PROGRESS. I know that INFORMIX is very portable but I >know little about it. I was wondering if anyone using any one of these three >products could give me some insight to the snags and successes of their use. > > I am looking for something that is very portable and allows access to >databases through C-code. Here are a few questions I would like answered: > > Are they programmable, and if so how flexible? > Are there database limitations in size other than disk space? > How fast are they? > How much disk space is required? > What other requirements (i.e. memory)? > Can I port the database from one type of machine to another easily? > Can I dynamically reconfigure pre-existing databases easily? > > If there are any other relational database managers that I have not >mentioned please do not hesitate to respond. ALL repsonses will be appreciated >and I will post a followup on responses if appropriate. > > Thanks in advance, > Mark Savage Can I interest you in Unix Mumps? It has been through some changes since I last ported it to the Z8000-based Plexus you folks had... Hokey ..ihnp4!plus5!hokey 314-725-9492 --- Hokey ..ihnp4!plus5!hokey 314-725-9492 Hi; Enclosed find an article I saved from the net a couple of months ago I don't know if this will help but here it is for what it's worth. Myself and another guy have started a small company doing vertical applications with database managers. Presently we have both Unify and Informix running on an Onyx 8002 micro. Both have their good and bad points. Unify tends to be a bit dificult unless the user is an accomplished programmer. Informix on the other hand is easier for someone who is a sophiscated user. The key words here are user and programmer. I'd be interested in finding out your views on the two dbms's so any feedback would be welcome. Bill Bruce AT&T-IS Montgomery Works ..ihnp4!mgwess!wcb Path: mgwess!mgnetp!hw3b!wnuxb!Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP> Unix Technical Digest Wed, 13 Feb 85 Volume 1 : Issue 16 Today's Topics: Relational Database Responses (2 msgs) Relational Database Responses ("holes" in files) ---------------------------------------------------------------------- Date: 8 Feb 85 17:29:34 GMT From: Janet Lee <JLEE@SUMEX-AIM.ARPA> Subject: Relational Database Responses 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 es 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 11. 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 tha| 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. ------------------------------ Date: 9 Feb 85 17:56:27 GMT From: guy@rlgvax.UUCP (Guy Harris) Subject: Relational Database Responses > 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 ------------------------------ Date: 9 Feb 85 20:04:06 GMT From: jdb@mordor.UUCP (John Bruner) Subject: Relational Database Responses ("holes" in files) One severe misfeature of "holes" in V6 was that the blocks would be allocated when the file was read EVEN IF THE FILESYSTEM WAS READONLY. If the filesystem was not physically write-protected this could corrupt it. It turns out that the "POSSIBLE FILE SIZE ERROR" messages can be useful in a bizarre case. If a crash leaves a "hole" in a directory (a condition which cannot occur normally, since disc blocks are never released from pre-4.2BSD directories), "namei" will get confused when trying to read the directory (I don't have the V7 source code handy, but as I recall "bmap" returns -1, but "namei" does not check for this because it "can't happen"). The device driver for the disc may catch the reference to a negative block number (many drivers check for a block number which is too large, but not for a negative block number) or it may decode the negative block number and try to seek to a non-existent cylinder. In any event, you can't read the directory beyond the missing block, and you may even be rewarded with a crash. This happened to us at Purdue/ECN a few years ago after a particularly nasty crash on a V7 11/70. We had to track down the file size errors, find the directories which were involved, and either unlink them or fix them the really hard way (adb). This problem was present in all of the versions of UNIX that I was aware of at the time except for V6 (because it automatically filled in "holes"). At the time I posted a bug fix for V7/4.[01]BSD/2.8BSD. I'll look for it, but since it was so long ago (and so far away) I'm not optimistic that I could find it to post it again. The 4.2BSE code is different. I haven't looked at it extensively, but Berkeley sent me a note after I reported the bug in 4.1BSD saying that the problem would be fixed in 4.2. I have no idea if it has been fixed in System V. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor.ARPA [jdb@s1-c] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!decvax!decwrl!mordor!jdb ------------------------------ End of Unix Technical Digest ****************************** -- Ronald W. Heiby / ihnp4!{wnuxa!heiby|wnuxb!netnews} AT&T Information Systems, Inc. Lisle, IL (CU-D21) You should perhaps look into MISTRESS, developed by RHODNIUS Inc. and marketed by Human Computing Resources (HCR) here in Toronto. It is a commercial version of MRS, an experimental relational database developed at the University of Toronto. I've used MRS quite a bit and was very happy with. MISTRESS is supposed to have most of the quirks worked out (faster, better program interface). I don't have HCR's address right here but you want I will send it along. Regards, George Hart, Computer X Canada Ltd. {cbosgd, decvax, harpo, ihnp4}!utcs!mnetor!george --------------------------------------------------------------------------- Another relational DBMS that you might want to look into is Mistress. This has been ported to a large number of Uniclones, so it would probably fit your bill. It's a (the?) product of Rhodnius, Ltd. (or perhaps Inc.). One path to them from your site is ihnp4!utcsri!rhodnius. Try the login john - that's probably right for John Kornatowski, president. Mistress is a good system, although my experience is pretty much limited to its precursor, MRS. For all the details that you want, you'd better go to the horse's mouth. If the path I gave you doesn't work out, send me mail and I'll phone them up and ask them to send you details. John Hogg Computer Systems Research Institute, UofT {allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsri!hogg ------------------------------------------------------------------------- In article <608@afinitc.UUCP> you write: > I am looking for something that is very portable and allows access to >databases through C-code. Here are a few questions I would like answered: > > Are they programmable, and if so how flexible? Unify has a very extensive C interface, but watch out for putting unify lib together with curses. Informix/SQL (they have 2 versions of Informix, 1 with sql) allows you to imbed query/updates in a C program and gives you a preprocessor in front of cc. > Are there database limitations in size other than disk space? Unify can run on raw disk (db = filesystem size) as well as regular unix files. No problem with Informix. > How fast are they? Unify is fast for large databases as it bypasses Unix filesystem triple indirection. > How much disk space is required? I'm not sure what the overhead is. > What other system requirements are there(i.e. memory)? We had a large (>250 relations >1000 fields) database and unify ate too much memory for us to run programs on a 16 bit machine (pdp11). For 'normal' db's or 32 bit cpus no problem. I do not have experience with Informix other than on 32 bit cpus (3B20 and 68k). > Can I port the database from one type of machine to another easily? Not in binary form. You must extract them into ascii files first. You will run into byte ordering problems (UNIX, XINU, NUXI, IXUN). Both Unify and Informix give you utilities to dump and load a database. But, a Unify data dictionary is also a database and you might have a little trouble moving it around. > Can I dynamically reconfigure pre-existing databases easily? No. The problem comes in especially for Unify when it is on raw disk and you change the size of a file. You then have to unload and reload the database. If you db is huge, you must run it to tape. This is the tradeoff for speed. > > If there are any other relational database managers that I have not >mentioned please do not hesitate to respond. Look at ingres. It is a 'horse of another color' in that it has much more functionality than Informix and Unify with, of course, a higher price. Both Unify and Informix are good products but, since they have differing strengths and weaknesses, you will have to look closely at the details. For example, is a superior C interface and speed more important than ease of porting the data dictionary? Disclaimer: Blame me for everything, the rest of the universe is innocent. voice=415 774-9576 (after June 1= 415 823-2441) uucp={ihnp4,ucbvax,cbosgd,decwrl,amd,fortune,zehntel}!dual!ptsfa!jmc -------------------------------------------------------------------------- I still like INGRES by Relational Technology. Blessed Be, Jeff Hull {decvax,hplabs,ihnp4,scdrdcf,ucbvax} 13817 Yukon Ave. trwrb!trwspp!spp2!jhull Hawthorne, CA 90250 34o3'15" N by 118o14'28" W -------------------------------------------------------------------------- In article <608@afinitc.UUCP> you write: > > Recently I have found a need for the use of a relational database >on both PC's and UNIX supermicros. I have been particularly looking at >INFORMIX, UNIFY, and PROGRESS. I know that INFORMIX is very portable but I >know little about it. I was wondering if anyone using any one of these three >products could give me some insight to the snags and successes of their use. > > I am looking for something that is very portable and allows access to >databases through C-code. Here are a few questions I would like answered: > I have used UNIFY a bit and like it a lot. It offers a SQL and good set of 'C' library routines as well as COBOL. It is very UN*X like and uses standard system communications and tools. Often you uses scripts to bridge routines. It seems fairly quick and virtually unlimited in capacity. There are hacks to allow for quicker operation if the respective system can support it. Maintenance is trivial for the most part, although I havn't found a way to rename a schema yet. It even warns against obvious pitfalls. Interanll security is very sophisticated, down to group, user, record, field. It also offers lots of goodies like the screen generators and menu handler. As for resources I have played with it in a PDP 11-23/73 and TRS(68000). It requires several meg of space for development and gobbles 100k for almost any database (preallocated). If memory is available it runs faster although 256k is workable (ugh). On the nonvirtual systems watch out for the page size. It oftens trys to create tables of the schema in SQL, and other routines. If it runs out of memory, too bad, culling time. Rick ...!cybvax0!fbp "A likely story. I don't believe a word of it." ---------------------------------------------------------------------------- You posted a query about DBMS systems recently. We have the same needs here, and wondered what you have found out. I have not seen an article posted. I have used Informix on MS/DOS, and we have a (free) demo version on the VAX, but I have not done any big systems with it. So far I am pleased with the tools provided, although not as fancy as some. I have seen a good deal about UNIFY, but have not used it. Ingres has been used by some people here, but I am not impressed. Please let me know what you query brought forth. Louis Schmittroth, Coordinator of Computer Science, Athabasca University. ...ihnp4!alberta!auvax --------------------------------------------------------------------------