danylkiw@hcrvx1.UUCP (Brian Danylkiw) (02/20/86)
Has anyone had any experience with the Knowledgeman (tm) or Knowledgeman/2 database product by MDBS (Micro Data Base Systems) ? It is currently implemented on the IBM-PC under MS/PC DOS and under BSD 4.2 on the VAX. It appears to be a very professional product with capabilities which make DB*SE-III and the like pale by comparison, especially in the richness of its programming language. Any comments, summaries would be greatly appreciated. Brian Danylkiw
6243tes@whuts.UUCP (STERKEL) (02/27/86)
> > Has anyone had any experience with the Knowledgeman (tm) or > Knowledgeman/2 database product by MDBS (Micro Data Base Systems) ? It > is currently implemented on the IBM-PC under MS/PC DOS and under BSD 4.2 > on the VAX. It appears to be a very professional product with capabilities > which make DB*SE-III and the like pale by comparison, especially in the > richness of its programming language. Any comments, summaries would be greatly > appreciated. > > Brian Danylkiw I have been using the K-Man 1.4 version for several years with great success. K-Man/II is a much enhanced version with full menu for those users who really do not know what a data base is and do not care, but "just gimme the answers". K-Man is probably the only *really relational* database manager program for the PC. Most pro- ducts such as DB/III do a good job of faking it. In the past, this *professional* and powerful product has suffered due to a small advertising budget, and we all KNOW that the so- called reviewers never seem to give a review or even know about products that currently are not advertising in their magazines. [Before you flame, go back over the last 5 years of reviews and note the strong correlation between reviews and size of advertise- ments in the same issue]. The second problem was a manual that made the brash assumption that the user was a professional that already understood the fundamentals of data base operations. The new K-Man/II has corrected this. K-MAN was the first relational DBMS to *include* (not after-market) text processing, spreadsheet (mediocre, maybe better now), real graphics, color/graphics, mouse control, forms, input/output forms, interactive forms control, a true Wirth-style language, C language interface. [For those who graduate from relational to "real databases", the same company markets MDBS III. This is a true brute of a product, with FORTRAN, assembly, C, COBOL, Basic, etc. interfaces, true network and data dictionary capability and full screen control. Not for the faint of heart ] *** REPLACE THIS LINE WITH YOUR MESSAGE ***
ac4@pucc-j (Tom Putnam) (02/28/86)
>> Has anyone had any experience with the Knowledgeman (tm) or >> Knowledgeman/2 database product by MDBS (Micro Data Base Systems) ? It >> is currently implemented on the IBM-PC under MS/PC DOS and under BSD 4.2 >> on the VAX. >> >> Brian Danylkiw In article <564@whuts.UUCP> 6243tes@whuts.UUCP (STERKEL) writes: >I have been using the K-Man 1.4 version for several years with great >success. K-Man/II is a much enhanced version with full menu for >those users who really do not know what a data base is and do not >care, but "just gimme the answers". I have K-Man 1.07 on a PC/AT. We have also been trying both K-Man 1.07 and now K-Man 2 under 4.2 BSD UNIX. These 4.2 versions have been Beta-test versions, so they probably have some problems that won't appear in the final delivered products. Now for some observations. First, I agree that K-Man is a powerful relational DMBS. It is also a fairly large package. You really don't want to use it if all you have is a floppy disk based system -- that's where Dbase and friends can probably claim a better niche. K-Man is designed for bigger problems. The big thing we have noticed with our UNIX versions is that they don't do screen management very well for people using ASCII terminals. We have a lot of terminals that are still running at 2400 bps (due to the large number of terminals and the limitations in our front-end switch). Watching K-Man repaint the screen over and over on a 2400 bps terminal is really painful. You probably wouldn't care as much at 9600 bps. BUT WAIT! Help is on they way! That's why they have Beta test sites. In version 1.07, they used their own screen manipulation package. They did not use termcap ... they had their own configuration files. That was a real problem for us with nearly 1000 terminals with dozens of different brands. We told them so. K-Man 2 has changed to termcap, but they still aren't very intelligent about repainting areas of the screen that haven't changed. You don't notice this when you have it on a PC because you can paint the PC's screen so quickly. Anyway, I am told they are working on a new version that will use something like curses, so that should help a bunch. While we are on the subject of K-Man 2 and its menus, I would have to say that using the menus is REALLY SLOW on an ASCII terminal. You just have too many levels and choices. For example, it takes two or three different menu selections just to get the thing to generate the BYE command so you can exit. I haven't seen K-Man 2 on a PC, but I'm sure it must be faster. Personally, I'm not so sure I would even use it there because of all the multiple levels and choices you have to make to do even the most simple things. Back to 6243tes@whuts.UUCP (STERKEL): >The second problem was a manual that made the brash assumption that >the user was a professional that already understood the fundamentals >of data base operations. The new K-Man/II has corrected this. Well, sorry to disappoint you. They say they have a new manual, and indeed they do. Sorry to say the only thing new about it is its form, not its content. It is now typeset and fits into one of those nice boxes that fit on your shelf. It still lacks anything that looks like a tutorial ... yet it is organized like a cross between a tutorial and a reference manual. But unlike a real reference manual, they put it in order by what you are doing (e.g. Defining and Using a Table, Table Sorting and Indexing, Data Retrieval and Statistics) and then within each chapter the order of commands is the order in which you might choose to use them (?). I thought most technical writers learned many years ago that reference manuals should be ordered alphabetically (by command). To make it worse, each command description is in order by novice, intermediate, and advanced topics, so when you go try to use it as a reference manual, you aren't sure whether you are looking up a novice or advanced topic so you have to search 3 sections of text. The manual is still just plain abysmal! >K-MAN was the first relational DBMS to *include* (not after-market) >text processing, spreadsheet (mediocre, maybe better now), real >graphics, color/graphics, mouse control, forms, input/output forms, >interactive forms control, a true Wirth-style language, C language >interface. Yes, they do have these packages ... for the PC environment. But do notice that each of them comes as a separate add-on that you must purchase. Even at discounted prices, you can easily end up spending close to $1,000 for the whole package. And the spreadsheet is still one of the worst examples of how do to a spreadsheet that I have ever seen. Don't buy it for that "feature" (which is part of the base package). I'm afraid this winds up sounding negative. It probably just shows my frustration in dealing with a very nice DBMS that comes so close to being just what you want and then has silly little things like a dumb screen interface on UNIX and a poorly organized manual stand in the way of excellence. -- Tom Putnam, Manager of User Services Purdue University Computing Center ARPANET: ac4@asc.Purdue.EDU or ac4@purdue-asc.ARPA BITNET: PUTNAMT@PURCCVM CSNET: ac4@purdue-asc-tn USENET: ac4@pucc-j.UUCP USMAIL: Mathematical Sciences Bldg. West Lafayette, IN 47907 PHONE: 317/494-1787
ark@ut-sally.UUCP (Arthur M. Keller) (03/01/86)
In article <564@whuts.UUCP> 6243tes@whuts.UUCP (STERKEL) writes: >[For those who graduate from relational to "real databases", ... Please explain what you mean by this, before I light my flametorch. -- ------------------------------------------------------------------------------ Arpanet: ARK@SALLY.UTEXAS.EDU UUCP: {gatech,harvard,ihnp4,pyramid,seismo}!ut-sally!ark
roger@inmet.UUCP (03/03/86)
I 've worked with KMAN for about two years now, starting with release 1.02. It's the best tool I've seen for putting reasonable-sized applications up on a PC in a hurry. Its best features are its embedded editor (costs about $150 but worth it), and its environmental variable scheme. It does not have a compiler for the command language, but by making intellegent use of the context files and macros, you can make compilation unnecessary, even for good- sized jobs. It seems to follow all the IBM BIOS rules pretty well - I've run it on Wang PC's and on True Blue AT's at 8, 9, or 10 MZ - no problem. If you want to do lots of slick user interface, I would recommend you also spring for the screen generator (another $150 bucks - MDBS operates a'la carte) Another nice feature is its text processor (a stripped down Troff-type markup language) which allows you to do KMAN or DOS calls within the text environment. Finally, there is a Lattice-C interface package, which still has some bugs. Given MDBS's track record, I would expect that the next release of the C-interface program will have them worked out.
6243tes@whuts.UUCP (STERKEL) (03/04/86)
> In article <564@whuts.UUCP> 6243tes@whuts.UUCP (STERKEL) writes: > >[For those who graduate from relational to "real databases", ... > > Please explain what you mean by this, before I light my flametorch. > -- > UUCP: {gatech,harvard,ihnp4,pyramid,seismo}!ut-sally!ark actually the answer is quite simple: in my occasional delving into the application of data base managers to real world problems, I find approximately 70% of the problems to be not "list" or "flat-file" oriented. These applications are in reality the need to intelligently and efficiently map "one-to-many", "many-to-one", and "many-to-many" situations, and linkages. I am then faced with the prospect of using a very powerful embedded language within a better relational dbms (K-Man 1.07/2 is the best example) to do *alot* of custom programming to force the linkages within the relational context or move up-scale to a "brute" "networking" dbms such as MDBS III. To provide one example, networking dbms's such as MDBS III will readily provide for the realities of genealogical research such as sibling relationships, marriage, multiple/serial marriages, polygamy, etc. without custom programing to sift through the data to "find" and "catagorize" same. (Incidentally, geneologies rarely match the ideal of the "family tree" forms sold by stationary stores. Thus, Heir- archal dbms's are rarely useful.) I am ill equiped to discuss the theoretical bases of data bases. Please get to a good technical (not computer hacker) library for a better explanation than I have provided.
ark@ut-sally.UUCP (Arthur M. Keller) (03/06/86)
Sterkel replied to my question asking what he meant by graduating from
relational databases to real databases. Relational databases can
store the necessary information to handle one-one, one-many, and
many-many relationships. I wonder why you say "networking" databases
as opposed to network databases. Network databases may explicitly
support such connects but require the user to explicitly navigate
through the database in a procedural manner. The relational database
approach allows for non-procedural navigation of substantially the
same record types (but calls them "relations" instead.
It is a valid criticism that current relational database systems are
not as efficient as some non-relational DBMSs. It is a valid
criticism that "classical" relational DBMSs have less "semantics"
than, say, network databases. But in network databases, all
retrievals involve writing programs, while this need not be the case
in a relational DBMS. Ad hoc queries are often allowed in relational
DBMSs, but rarely allowed in network or hierarchical DBMSs. In time,
commercial relational DBMSs will become more efficient, in parallel
with research technology advancing beyond.
Arthur
--
------------------------------------------------------------------------------
Arpanet: ARK@SALLY.UTEXAS.EDU
UUCP: {gatech,harvard,ihnp4,pyramid,seismo}!ut-sally!arkpavlov@hscfvax.UUCP (840033@G.Pavlov) (03/06/86)
Re network, hierarchical vs relational ( == MDBS III vs K-Man 2 ???? )
-- my suspicion is that Mr. Sterkel expects us to find Mr. Codd's and Mr.
Date's works in the "Computer Hacker's Library".
- and 1960's James Martin in the "Technical Library"
:-) :-) :-) g. pavlov.burd@unmc.UUCP (burd) (03/08/86)
In article <> ark@sally.UUCP (Arthur M. Keller) writes: >Network databases may explicitly >support such connects but require the user to explicitly navigate >through the database in a procedural manner. The relational database >approach allows for non-procedural navigation of substantially the >same record types (but calls them "relations" instead. > >But in network databases, all >retrievals involve writing programs, while this need not be the case >in a relational DBMS. Ad hoc queries are often allowed in relational >DBMSs, but rarely allowed in network or hierarchical DBMSs. In time, >commercial relational DBMSs will become more efficient, in parallel >with research technology advancing beyond. > The contention that all retrievals in a network database involve writing programs is simply not true. A good example being the QRS subsystem of the MDBS III network DBMS. This system will allow you to generate output reports by specifying data items to be retrieved, conditions to be met (e.g., all records from New Mexico), and the sets to be traversed (in the proper order). This type of non-procedural query facility is available on many other network DBMSs as well. I've heard arguments to the effect that such a query system is difficult to use as the user must know actual record/field names and specify the proper search path. This is true, but is not much more difficult than specifying similar queries in Kman (where actual table/field names must be used and proper selection of a search path via redundant data fields is tricky). I've used both systems (and Dbase III) extensively for teaching and personal use and I've found little advantage of relational query languages over network query languages. FROM: Stephen D. Burd USNAIL: Anderson Schools of Management University of New Mexico Albuquerque, NM 87131 AT&T: (505)-277-6418 UUCP: {lanl,ucbvax!unmvax,gatech!unmvax,...}!unmc!burd
6243tes@whuts.UUCP (STERKEL) (03/09/86)
> Re network, hierarchical vs relational ( == MDBS III vs K-Man 2 ???? ) > > -- my suspicion is that Mr. Sterkel expects us to find Mr. Codd's and Mr. > Date's works in the "Computer Hacker's Library". > - and 1960's James Martin in the "Technical Library" > > :-) :-) :-) g. pavlov. opinions about spreadsheets, databases, languages, etc. frequently take on the trappings of religion. as my short and inadequate explanation about relational vs. network database managers exposed even I (occasionally :-) fall victim to religiosity. At least this net qroup is not victimized like net.religion, and the responses to my faux pas of overstating my case have been gentle.