Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!uwvax!dogie.macc.wisc.edu!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!rex!ames!sgi!shinobu!odin!hargrove From: hargrove@harlie.sgi.com (Mark Hargrove) Newsgroups: comp.databases Subject: DB engine embedded in the OS? Message-ID: Date: 17 Aug 89 23:47:54 GMT Sender: news@odin.SGI.COM Distribution: comp Organization: Silicon Graphics Inc, Mountain View, CA Lines: 28 Over the last 2 million years (well, 9 months actually, but we've been dealing with salesmen, so it seems longer...), we've heard a LOT about the various strategic directions that the major 6 or 7 DB suppliers will be taking. Several common themes have emerged, and one interesting dichotomy. One group of vendors (most notably DEC and Tandem) are making very strong arguments that most, if not all, of a DB engine should be embedded in the operating system. Tandem is basically in the state already; DEC insists they will be. Both argue that high performance DB's *require* this approach. The other group of vendors argue that this is just not so -- except for extreme cases, even heavy OLTP applications can be run with the DB engine as a "normal" process, running on top of an OS. Their arguments are generally based on the notion that MIPS (and to a lesser extent, disk I/O's) are cheap -- and getting cheaper fast. Performance can always be increased by throwing cheap MIPS and faster disks at the problem. [well, the argument is more sophisticated than this, but you get the drift]. Our own evaluation team is religiously divided on this subject. What are your thoughts on this issue? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark Hargrove Silicon Graphics, Inc. email: hargrove@harlie.sgi.com 2011 N.Shoreline Drive voice: 415-962-3642 Mt.View, CA 94039