fuller@kadsma.uucp (Bill Fuller) (10/11/89)
Hi, I am about to embark on project where the client will be asking me to develop a system using the dbVista package. I know very little about it other than it is a network database that you can get the source for. I would reaaly appreciate any comments on it from people who have used it, and any comparisons that could be made to better know products. One other note; I will be using a SUN under SunOS 4 for the project. Thankyou ahead of time, Bill Fuller fuller%kadsma@kodakr
jhc@iris.brown.edu (James H. Coombs) (10/13/89)
In article <1989Oct11.141207.18348@kadsma.uucp> fuller@kadsma.uucp (Bill Fuller) writes: > I am about to embark on project where the client will be asking me >to develop a system using the dbVista package. I know very little about it >other than it is a network database that you can get the source for. I would >reaaly appreciate any comments on it from people who have used it, and any >comparisons that could be made to better know products. One other note; I >will be using a SUN under SunOS 4 for the project. We have used Faircom's c-tree for a year now, with very good results. (We used Ingres before, but we had a lot of problems with database administration, and few wanted to purchase and install Ingres so that they could run Intermedia.) c-tree does not have a good ad hoc query capability, so I ordered the recent special: db_Files and db_Retrieve. (The names may be slightly off.) I sent it back. Why? 1. No varying length records. c-tree supports not only varying length records but also compression of keys in indexes. I have databases of 25 Mb and up, so compression (of English words, file pathnames, etc.) can save a lot of space. 2. The network model sounds good at first, but the overhead for the pointers to the next and previous records in the set adds up quickly. I have forgotten the details of the data structures, but my judgment was that I would not save significant space. 3. Retrieval of a set from the network model should be faster than traversing an index---but how much faster? I don't have performance problems with c-tree, so there is not much motivation to do the work required to make a full comparison. 4. c-tree uses Unix record locking. db_Files locks entire files or leaves it to the application developer to implement their (simple) record-locking scheme. 5. I was after the SQL. The documentation for db_Files was very impressive; the documentation for db_Retrieve was not. db_Retrieve included an ad hoc apparatus for marrying SQL to the network database. I never worked through the details. db_Retrieve does not optimize queries. My judgment was that I would be inviting trouble and would have to implement my own query engine in the end anyway. db_Vista and db_Query may be a lot better. My impression is that they are not enough better to justify the cost. In any case, my experience with c-tree is very positive, and db_Files/db_Retrieve did not look good enough to inspire further investigation at this time. I heartily recommend c-tree, and I'm in very good company on this recommendation. (I found that people on bix recommend c-tree and rarely mention db_...) r-tree is ok; I use it once in a while. I sent d-tree back; although it may be better now, it doesn't address our needs anyway. --Jim Dr. James H. Coombs Senior Software Engineer, Research Institute for Research in Information and Scholarship Box 1952, Brown University, Providence, RI 02912
fr@icdi10.UUCP (Fred Rump from home) (10/16/89)
In article <17731@brunix.UUCP> jhc@iris.brown.edu (James H. Coombs) writes: ->In article <1989Oct11.141207.18348@kadsma.uucp> fuller@kadsma.uucp (Bill ->Fuller) writes: ->> I am about to embark on project where the client will be asking me ->>to develop a system using the dbVista package. I know very little about it ->>other than it is a network database that you can get the source for. I would ->>reaaly appreciate any comments on it from people who have used it, and any ->>comparisons that could be made to better know products. One other note; I ->>will be using a SUN under SunOS 4 for the project. -> ->We have used Faircom's c-tree for a year now, with very good results. (We ->used Ingres before, but we had a lot of problems with database ->administration, and few wanted to purchase and install Ingres so that they could run Intermedia.) c-tree does not have a good ad hoc query capability, ->so I ordered the recent special: db_Files and db_Retrieve. (The names may ->be slightly off.) I sent it back. Why? I believe you're comparing apples and oranges here. First of all I would presume that Bill Fuller is obtaining the db_VISTA package not db_Files and Retrieve. Both are rather elementary products not worthy of serious development but rather a quick and dirty one. No wonder you sent them back. A C-Tree access mechanism is NOT a data base: VISTA is - both network and relational. In its price range, with source code, it is the one tool that permits full compatibility with just about any hardware out there. There is no need to wait for features you desperately need or bugs you need fixed which can put the developer into a serious quandary when product has to be delivered. Here you get your best guys on the project and do it yourself. (If needed) I don't know of any other database package that gives you source without also wanting a mortgage on the house. Technically there is quite a bit of similarity with MDBS III, long a premier seller to corporate and government users for their high end applications. But Vista (Raima) seems to have learned a lot from the problems of MDBS and has improved its product substantially. [listing of drawbacks of db_Files and Retrieve] ->db_Vista and db_Query may be a lot better. My impression is that they are ->not enough better to justify the cost. In any case, my experience with ->c-tree is very positive, and db_Files/db_Retrieve did not look good enough ->to inspire further investigation at this time. Well, if you could manage with C-Tree, you did not need a database and your decision was the correct one. You obviously would have had too much in resources available for your application. ->I heartily recommend c-tree, and I'm in very good company on this ->recommendation. (I found that people on bix recommend c-tree and ->rarely mention db_...) r-tree is ok; I use it once in a while. I sent ->d-tree back; although it may be better now, it doesn't address our needs ->anyway. Again, the users of Vista are mostly professional developers in the vertical market place. They would typically not post to bix. They don't even post here which is somewhat sad because we could all learn a little more about combined relational/network technology. The 5000+ licenses sold are mostly in the business world where they tend to disappear beneath the product. >Dr. James H. Coombs >Institute for Research in Information and Scholarship >Box 1952, Brown University, Providence, RI 02912 Fred Rump -- This is my house. My castle will get started right after I finish with news. 26 Warren St. uucp: ...{bpa dsinc uunet}!cdin-1!icdi10!fr Beverly, NJ 08010 domain: fred@cdin-1.uu.net or icdi10!fr@cdin-1.uu.net 609-386-6846 "Freude... Alle Menschen werden Brueder..." - Schiller
jhc@iris.brown.edu (James H. Coombs) (10/20/89)
In article <456@icdi10.UUCP> fr@icdi10.UUCP (Fred Rump from home) writes: > I believe you're comparing apples and oranges here. > First of all I would presume that Bill Fuller is obtaining the db_VISTA > package not db_Files and Retrieve. Both are rather elementary products not > worthy of serious development but rather a quick and dirty one. No wonder > you sent them back. Ok, so what does db_Vista offer? > A C-Tree access mechanism is NOT a data base: VISTA is - both network and > relational. What makes db_Vista a relational data base? What does c-tree lack? > In its price range Which is what? Someone sent me mail asking about the price of c-tree. I see that Programmer's Connection is advertising it for $315 (includes source). I can't find a price on db_Vista. As I recall, it was something like $2500 for db_Vista and another $2500 for db_Query. There is also db_Revise. > In its price range, with source code, it is the one tool that > permits full compatibility with just about any hardware out there. There > is no need to wait for features you desperately need or bugs you need fixed > which can put the developer into a serious quandary when product has to be > delivered. So, db_Vista has record-level locking? not just a suggested method for application developers to implement their own record locking? It has variable length records? It has (via db_Query) a full SQL that does not require one to declare access paths first and that optimizes queries? > Fred Rump Do you work for Raima, Fred? --Jim Dr. James H. Coombs Senior Software Engineer, Research Institute for Research in Information and Scholarship Box 1952, Brown University, Providence, RI 02912
fr@icdi10.UUCP (Fred Rump from home) (10/22/89)
In article <18389@brunix.UUCP> jhc@iris.brown.edu (James H. Coombs) writes: >In article <456@icdi10.UUCP> fr@icdi10.UUCP (Fred Rump from home) writes: >> I believe you're comparing apples and oranges here. >Ok, so what does db_Vista offer? Since there seems to be some question as to what this product is let me expound for the benefit of all for a moment. >> A C-Tree access mechanism is NOT a data base: VISTA is - both network and >> relational. > >What makes db_Vista a relational data base? What does c-tree lack? Perhaps I stretched the point of purely relational as per database standard specifications. But then every product seems to claim the title without regard for claims of purity. Vista is a real 'network' type database. But it does and can operate from a relational view. In its most basic sense a network model is essentially also relational. A table is a record type; a row is an occurrence; a column is a field. But what is unique to the network model is the additional ability to directly define various relationships between record types. These relationships, using sets, can be one-to-many, many-to-one or many-to-many according to owners and members. Transparent pointers relate these sets to each other. Such set is really a pre-defined join from the relational model. While standard SQL relational technology presently only provides for inner joins such restriction is not the case in 'viewing' the vista network model. Typically a set path from member to owner provides an inner join while owner to member does the outer join. The situation of preset joins necessitates database design up front in the relational model but has the tremendous performance advantage over the relational in that unnecessary indexing cuts disk access requirements by perhaps two or three reads per record requirement. Space requirements are also reduced. For large databases, with many system and other sets and where speed is essential in providing linkages based upon random conditions, these factors often make a network the only optional database tool to be considered as functional. >> In its price range > >Which is what? Someone sent me mail asking about the price of c-tree. >I see that Programmer's Connection is advertising it for $315 (includes >source). I can't find a price on db_Vista. As I recall, it was something >like $2500 for db_Vista and another $2500 for db_Query. There is >also db_Revise. With source you're in the ballpark. I think I paid around $7000 for the package. Remember it's a one time deal. A few Oracle run-times will match that quickly and add up to real dollars over time if the product sells. >So, db_Vista has record-level locking? not just a suggested method for >application developers to implement their own record locking? It has >variable length records? It has (via db_Query) a full SQL that does not >require one to declare access paths first and that optimizes queries? Heh, we have the source. We can do whatever we want with it. That was the whole point of my previous note. I pay expensive programmers with all kinds of advanced degrees and experience levels to do these things. But I have control. And we don't need variable length records. Our textual data is handled internally using as many multiple fixed length records as needed. The user thinks he's doing wordprocessing in the database where this is applicable. As developers we control the database design. We also provide all the facilities to get information the user would wish to see in any way or fashion that turns him on. Data extracts for mail-merge with any wordprocessor, reports of user design, labels in any of many possible sequences, the list goes on and on. But still we are toying with the idea of using IQ (Intelligent Query) as a front end. This is available for relational databases (like Informix, Unify, Oracle) too. The jury is still out as to its need. >Do you work for Raima, Fred? >Dr. James H. Coombs Obviously my signature says otherwise. I simply went looking for the best product to use for my best product. In the vertical I play in I don't intend to ever be #2 and I certainly would be right in the pack if I used something like C-Tree - or at the bottom with a dbase III type product. Quick and dirty stuff is one thing, but this is multi-user-land and the expectations are a little higher; as is the price. PS Perhaps you missed the recent issue of PCWEEK where Vista was rated number 1 for database development products in functionality and flexibility. It lost the overall rating as number one because it has no front end like YAM or some other screen design feature. So over-all it was only #2. Like I said, it's only for developers to do their own thing. The user never sees the name. Fred Rump -- This is my house. My castle will get started right after I finish with news. 26 Warren St. uucp: ...{bpa dsinc uunet}!cdin-1!icdi10!fr Beverly, NJ 08010 domain: fred@cdin-1.uu.net or icdi10!fr@cdin-1.uu.net 609-386-6846 "Freude... Alle Menschen werden Brueder..." - Schiller
fred@cdin-1.UUCP (Fred Rump) (10/28/89)
Anyone interested in further information may also wish to read the current
copy of DBMS (Nov 1989) magazine.
Alternatively I could summarize if there is interest.
Fred Rump
--
Fred Rump | UUCP: {uunet bpa dsinc}!cdin-1!fred
CompuData, Inc. | or ...{allegra killer gatech!uflorida decvax!ucf-cs}
10501 Drummond Rd. | !ki4pv!cdis-1!cdin-1!fred
Philadelphia, Pa. 19154| Internet: fred@cdin-1.uu.net (215-824-3000)fr@icdi10.UUCP (Fred Rump from home) (11/07/89)
In article <16252@netnews.upenn.edu> catone@dsl.cis.upenn.edu (Tony Catone) writes: >In article <309@atti07.ATT.COM> mjm@atti07.ATT.COM (Michael Matthews x7776) writes: > >In article <335@cdin-1.UUCP> fred@cdin-1.UUCP (Fred Rump) writes: This is in request to summarize an article by Lan Barnes (a San Diego based free-lancer specializing in C and Database applications) appearing in the Nov issue of DBMS magazine. "Catching up to db_VISTA" 'The PC market is finally ready for a product that brings mainframe tools to micros' Barnes had apparently reviewed Vista back in 1984 and praised it as a coming smash hit. "I miscalculated ... because I ignored the reality of the marketplace. The mainframe people ... were ignoring micros." His premise is that the micro programmers were looking for ease and speed of implementation and found relational models usable without help from the stuffy mainframe people who wanted little to do with micros anyway. On the other hand the mainframers did not think a real database belonged on a toy micro and did nothing to implement real work in such environment. (We know the story) He claims a new class of customer/user has entered the marketplace now. They wish to use micros but find their needs far outstripping the traditional RDBMS packages available. These designers wish a migration path across a variety of operating systems and hardware configurations. They wish and expect the performance and portability only found in tight C code. MIS directors in corporate America supposedly have found all this and more in db_Vista. A lot of discussion comparing the relational model to the network model follows. He explains that Vista offers both the B-tree relational model and the network set linkage in the same database. He further explains how Vista handles the many-to-many relationship thru the use of an 'intersect' record that does nothing but point to its owners. A variety of real life examples are given to point out the ease of one versus the difficulty of the other. Vista's data dictionary is described as storing typical information about ownership, locations and relations of data fields, records and sets. Because page size is under programmer control (as is really everything) database optimization can be judiciously handled thru parameter selection. He then points out that development is not for the faint-hearted. That this can not be compared to dBASE or R:Base and is strictly for professionals. He calls them 'developers engaged in full life cycle production'. In this regard he refers to the included TIMS (Technical Information Management System) as an excellent on-line tutorial. The reviewer's own difficulties with Vista in developing a from-scratch Checkbook writing system as a test, he blames on the need to think completely different from years of work using relational model databases. The review finishes with a discussion of various available library routines for database revision, import and export, WKS C library for Lotus and Dbase III compatible file formats, and IDA the Interactive Database Administrator tools. The Multi-user aspects of Vista appeal to the Unix and DOS network developer thru the use of transaction logging with commit and rollback. A lockmanager permits complete programmer control of all locks to files, records or indexes. User ID's are stored along with transactions and timestamps for automatic recovery in case of a dataloss. db_Vista also offers transparent database distribution which essentially means that physical locations of data can be spread across various nodes on the network or different file servers. PROS and CONS "db_Vista's disadvantage as a database development tool is the source of its many advantages - it demands C programming. On the downside, this means that db_Vista is not easily accessible or appropriate for casual use. On the other hand, it means small, fast programs can utilize the myriad available excellent communications, windows, and just about anything else imaginable. db_Vista is fit for large custom projects, with a built-in migration path from DOS to most other significant operating systems. It is a professional tool with sound documentation and excellent company support. db_Vista deserves an unqualified recommendation for serious database program development." Raima's phone number is 800-327-2462 (fax 206-7471991) Bellevue, WA **** Notes by fr: As a user of this product we, understandably, had to justify its selection from available market choices. The reader may wonder what made us opt for this product. #1 As a software developer with an in-depth vertical, spreading the development cost across a maximized hardware/OS field was the primary selection criterion. #2, and a close second, was the control factor permitted by the use of source code. This offers freedom from the mutations of the market as long as we can manage to survive in it. #3 The technical capability of the Vista network/relational database suits itself to our idea of database design. (This may come from years of work on mainframe database systems. Perhaps home is where you cut your teeth.) #4 The price was right in that royalties or run times are history. #5 The availability of an enhanced SQL to provide ad hoc reports or screen listings. #6 Our application requires that data present itself implicitly to a neophyte user who assumes the computer should "know" what he/she wants. IE sorting is not an option. Data must already be linked his way somehow intuitively. Fred Rump -- This is my house. My castle will get started right after I finish with news. 26 Warren St. uucp: ...{bpa dsinc uunet}!cdin-1!icdi10!fr Beverly, NJ 08010 domain: fred@cdin-1.uu.net or icdi10!fr@cdin-1.uu.net 609-386-6846 "Freude... Alle Menschen werden Brueder..." - Schiller