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