andrew@lccinc.UUCP (Andrew Scholnick) (07/19/90)
I have recently taken over managing a product which is using the db_VISTA III network-model database package. I am putting together a justification for continuing to use db_VISTA. While there are some obvious basic technical reasons why the network-model is more appropriate for the application being developed, I could use some help defending staying with db_VISTA rather than going to a 'more established' relational-model product and 4GL. Does anyone have any information (statistics, rational arguments, etc...) which might help me further support a decision to stay with the db_VISTA product? Please email me any answers. If I get any requests to see the information I collect I will be glad to forward summaries. If there is great interest I will summarize to the NET. Thanks. ARS.
ericd@ms.uky.edu (Dan Chaney) (07/20/90)
E-mail bounced to 'andrew@lccinc.uucp'...
My group just compared db_VISTA, MDBS_V, Informix, and Ingres on MS-DOS. We
will be supporting our application under SunOS as well.
We chose db_VISTA for the following reasons:
Network model is fine for our application.
C library MUCH better to program in than imbedded language.
A 4GL might be "powerful" but it isn't as flexible as C with libraries.
The 4GLs where geared toward their forms interface, again not nearly as
flexible as a C user interface library.
db_VISTA can undoubtedly outperform the 4GLs under DOS.
Technical support has been good.
Its inexpensive, no run time licenses.
Its portable to a large number of environments.
You can get full source.
It has a reasonable SQL interface.
It doesn't require a memory resident module in DOS and therefore is not
a "memory hog".
Function calls are straightforward and easy to use.
At least 8 people on the net recommended it highly to me.
... and the list goes on, but these are most of the major factors for us.
Eric
--
[] Eric B. Durbin (606) 257-4581 [] ericd@ms.uky.edu []
[] University of Kentucky [] ericd@UKMA.BITNET []
[] 165 Markey Cancer Center [] {rutgers, uunet}!ukma!ericd []
[] Lexington, KY 40536-0093 [] eric.durbin@ukwang.uky.edu []fred@cdin-1.UUCP (Fred Rump) (07/21/90)
andrew@lccinc.UUCP (Andrew Scholnick) writes: >Please email me any answers. If I get any requests to see the >information I collect I will be glad to forward summaries. If there is >great interest I will summarize to the NET. Your UUCP address is apparently not well known. After several bounces I finally may have reached your site thru uunet!lccinc. Can you confirm? fred -- Fred Rump | UUCP: {uunet dsinc}!cdin-1!fred CompuData, Inc. | "Beware of cats for they are subtle and will .... on 10501 Drummond Rd. | your computer." Philadelphia, Pa. 19154| Internet: fred@COMPU.COM (215-824-3000)
dkeisen@Gang-of-Four.Stanford.EDU (Dave Eisen) (07/24/90)
In article <15660@s.ms.uky.edu> ericd@ms.uky.edu (Eric B. Durbin) writes: > >We chose db_VISTA for the following reasons: I concur wholeheartedly. It's flexible and very easy to use, it doesn't cost anything to use it in our products. The source code is clean and easy to understand (and modify if need be). But the overriding factor is just how fast it is. We compared it to other databases (Oracle, Informix, ...) and there was simply no comparison. I'm absolutely sold on Vista. -- Dave Eisen Home: (415) 323-9757 dkeisen@Gang-of-Four.Stanford.EDU Office: (415) 967-5644 1447 N. Shoreline Blvd. Mountain View, CA 94043
cohend@roadkill.rtp.dg.com (Dave Cohen) (08/08/90)
Eric -
In general, I agree with this. I am also looking at db_VISTA.
But I disagree on a couple points.
In article <15660@s.ms.uky.edu>, ericd@ms.uky.edu (Dan Chaney) writes:
|> E-mail bounced to 'andrew@lccinc.uucp'...
|>
|> My group just compared db_VISTA, MDBS_V, Informix, and Ingres on MS-DOS. We
|> will be supporting our application under SunOS as well.
|>
|> We chose db_VISTA for the following reasons:
|>
|> Network model is fine for our application.
|>
|> C library MUCH better to program in than imbedded language.
Using function calls is much more difficult than using an embedded
language. Plus, a good SQL implementation will preoptimize and
store the embedded statements.
|>
|> A 4GL might be "powerful" but it isn't as flexible as C with libraries.
|>
|> The 4GLs where geared toward their forms interface, again not nearly as
|> flexible as a C user interface library.
|>
|> db_VISTA can undoubtedly outperform the 4GLs under DOS.
|>
|> Technical support has been good.
|>
|> Its inexpensive, no run time licenses.
The 'no run time license' is a big win.
|>
|> Its portable to a large number of environments.
|>
|> You can get full source.
|>
|> It has a reasonable SQL interface.
No - it can only query thru the SQL interface using SELECT statements,
plus you have to set up your own views. There is no DELETE, UPDATE, or
INSERT statement support.
|>
|> It doesn't require a memory resident module in DOS and therefore is not
|> a "memory hog".
|>
|> Function calls are straightforward and easy to use.
|>
|> At least 8 people on the net recommended it highly to me.
|>
|> ... and the list goes on, but these are most of the major factors for us.
|>
|> Eric
|>
|> --
|> [] Eric B. Durbin (606) 257-4581 []
ericd@ms.uky.edu []
|> [] University of Kentucky []
ericd@UKMA.BITNET []
|> [] 165 Markey Cancer Center [] {rutgers,
uunet}!ukma!ericd []
|> [] Lexington, KY 40536-0093 []
eric.durbin@ukwang.uky.edu []
|>
David Cohen | "There's nothin' wrong with goin'
cohend@dg-rtp.dg.com | nowhere, baby, but we should be
{world}!mcnc!rti!dg-rtp!cohend | should be goin' nowhere fast."
Data General Corporation, RTP, NC| - Streets of Fire paulf@lamont.ldgo.columbia.edu (paul friberg) (08/09/90)
Another addition to the list of problems with db_vista III is its lack of networking (i.e., client/server communications). This is fine if you are operating in a homogeneous network where you can NFS mount your data disk on every host from which you wish to access the data base. For a heterogeneous network, however, you are basically screwed. Can anyone offer any insight into db_vista as to how it does its IPC? Paul Friberg (paulf@lamont.ldgo.columbia.edu) Lamont-Doherty Geological Observatory of Columbia University
rob@lafayet.Lafayette.LA.US (Rob Freyder) (08/09/90)
In <1990Aug8.144318.10203@dg-rtp.dg.com> cohend@roadkill.rtp.dg.com (Dave Cohen) writes: >Eric - > In general, I agree with this. I am also looking at db_VISTA. > But I disagree on a couple points. >In article <15660@s.ms.uky.edu>, ericd@ms.uky.edu (Dan Chaney) writes: >|> We chose db_VISTA for the following reasons: >Using function calls is much more difficult than using an embedded >language. Plus, a good SQL implementation will preoptimize and >store the embedded statements. >|> A 4GL might be "powerful" but it isn't as flexible as C with libraries. I am not so sure... We love the speed of dv_vista but are thinking of moving to Informix 4GL and Wingz due to the options we give our users ! Although maybe these options dont exist under dos. db_vista lacks a friendly SQL interface and report writer ... while the code *is* fast... the users have no friendly avenue for ad hoc queries ! Something we desparately need.. (who doesnt ?) We also want to be able to query databases on different machines transparently ..(see Informix-Star) which we cant do with db_vista products ! >|> It has a reasonable SQL interface. >No - it can only query thru the SQL interface using SELECT statements, >plus you have to set up your own views. There is no DELETE, UPDATE, or >INSERT statement support. I agree... Its SQL interface is far from reasonable. Our schema was monstrous when we got done... (Laboratory Information Mgmt Sys...) and the joins were mind boggling... Forget it with db_Query. we even tried IQ ... they have a Report Writer for Bean Counters... Great for relational databases but horrid for sets... Somebody needs to come up with a good report writer / SQL interface to db_vista databases before it will be widely accepted. Dont get me wrong... We love the speed but ... novice users can't interact with it except through the code *you* write for them ! Unless they are SQL wizards... I await you reply. -- Rob Freyder Core Laboratories a division of ____ ____ ____ Western Atlas International a \ \ / /\ / /\ Litton/Dresser Company \ \/ / \ / / \ (318) 235-9431 \ / / \ / /\ \ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= \/___/ \/___/ \___\ ...!uunet!rouge!lafayet!rob
fred@cdin-1.UUCP (Fred Rump) (08/10/90)
rob@lafayet.Lafayette.LA.US (Rob Freyder) writes: >Dont get me wrong... We love the speed but ... novice users can't interact >with it except through the code *you* write for them ! Unless they are >SQL wizards... Ah, but there's the trick isn't it. As a free from type database where the users interact ala their own report extraction via an SQL interface, forget it. Our users wouldn't know SQL from RPG anyway. So one writes his own monster programs that do everything the user would ever wish to do in your own menu driven extract report generator/file extractor/mailmerger/whatever. This can only work in vertical packages written for multiple resale applications where a high degree of 'custom' development can be justified, obviously. Any one time in-house application couldn't or wouldn't write their own SQL language either. So for the one time job where lots of options must be retained Vista is not the tool, but it's hell on wheels if you plan to really implement a system to beat all systems. fred -- Fred Rump | UUCP: {uunet dsinc}!cdin-1!fred CompuData, Inc. | "Beware of cats for they are subtle and will .... on 10501 Drummond Rd. | your computer." Philadelphia, Pa. 19154| Internet: fred@COMPU.COM (215-824-3000)
dave@dptechno.UUCP (Dave Lee) (08/10/90)
In article <2660@lamont.ldgo.columbia.edu> paulf@lamont.ldgo.columbia.edu (paul friberg) writes: >Another addition to the list of problems with db_vista III is its >lack of networking (i.e., client/server communications). This is >fine if you are operating in a homogeneous network where you can >NFS mount your data disk on every host from which you wish to access >the data base. For a heterogeneous network, however, you are basically >screwed. > >Can anyone offer any insight into db_vista as to how it does >its IPC? I use db_vista III under unix and have developed a product that uses it in a multi-user,multi-computer network. DB_vista has support for multi-computer networks under DOS, using LAN manager system locking. Under unix, there is direct support for multi-USER, single CPU systems. Data is stored in binary form in the host`s native format. IPC is through the OS-specific system calls (message queues on SYSV, sockets on BSD). There is support for a system independant locking stratagy that relies solely on lock files in a common directory. This technique is not recomended due to high file access overhead. This MAY work on multi-computer networks using NFS, but I havent tried it. However, all CPU's must share the same basic data representation. The system I constructed used a server host running a db_vista back end for every active user. A front end on the client cpu communicates with the back end on the host via a RPC interface. All data transmited to/from the backend is in ASCII and encoded/decoded at each end. Also high level commands are implemented such as update,create,query ... I find this scheme quite acceptable, although it did require a good deal of my coding to implement. -- Dave Lee uunet!dptechno!dave