Path: utzoo!attcan!uunet!seismo!dimacs.rutgers.edu!rutgers!mcnc!beguine!durham!robinson
From: robinson@durham.med.unc.edu (Gerard A. Robinson)
Newsgroups: comp.databases
Subject: Re: Ingres acquisition by ASK (plus a hopefully fun question)
Keywords: Ingres, ASK
Message-ID: <1133@beguine.UUCP>
Date: 22 Sep 90 15:18:16 GMT
References: <4435@avocado20.UUCP> <1124@beguine.UUCP> <28051@pasteur.Berkeley.EDU>
Sender: usenet@beguine.UUCP
Reply-To: robinson@uncmed.med.unc.edu (Gerard A. Robinson)
Organization: UNC-CH School of Medicine, Office of Information Systems
Lines: 65


My original question was:

# How about some fun :-)  A while back, in this group, Dr. Stonebraker made
# the statement that database servers will be so plentiful that they'll be
# a-dime-a-dozen.  I disagree, I think that *GOOD* db servers (i.e. rock-solid
# reliability with fast response time) will be so rare, that THEY'LL decide
# the marketplace.

In article <28051@pasteur.Berkeley.EDU> mao@postgres.Berkeley.EDU (Mike Olson) writes:
>i'll bite.  you should probably discount my opinion, since i work for
>dr. stonebraker.
>
>i believe that the evolution of servers in the industry toward ansi SQL
>and generally identical functionality among vendors reinforces stonebraker's
>claim.  most commercial database systems *are* rock-solid, in terms of
>commits succeeding and rollbacks really rolling back.  ( some deleted text
>... )  in what sense is any commercial database system more solid than
>any other?

In the sense that other things don't happen.  An example from my experience
with INGRES 5.0 (not server technology, but still illustrative) is that a
btree structure could somehow get "a tiny bit corrupted" so that on a 
SPARC RISC system which is sensitive to data alignment boundaries, the OS
would panic with a "memory alignment" error and crash the system.  The 
problem could be fixed by finding the errant table and re-modifying it
(the re-modify would usually succeed although sometimes re-crash the
system) although we never found or received a remedy (in favor of V.6.3).
No data was lost, but time and energy certainly were.  Its these little
*extras* that the users don't like, and that *all* db servers (from reading
this list) have in some measure or another.  So 'rock-solidity' includes
(the absence of) these.

>
>so why do people choose one vendor over another?  because the front-end
>tools are better.

Indeed.  This was a large part of our decision to stick with INGRES four
years ago, when a new director (and thus new and expanded development push)
arrived.

>
>i think the acquisition of ingres corp. by ask is significant.  ask builds
>hot front-end tools for the ingres backend.  ingres was having financial
>problems selling its database system because database systems aren't what
>attract users.  ask, which ignores the database system in favor of selling
>tools that use it, made heaps of cash.
>
> (deleted paragraph)
>
>as commercial database systems continue to become indistinguishable from
>one another, the only thing that users will care about is the tools they
>can get.  those tools will, in general, run on all commercial database
>systems.  this is an exact parallel of the open systems revolution happening
>among hardware and os vendors these days.

I don't disagree.  In fact, this is almost my starting point.  OSs are even
lower on the food chain than rdbms systems and two is still one too many for
most open system proponents.  When does INGRES, for example, start producing
tools for Oracle and Sybase servers?  Then, when do they make the decision to
stop, for financial reasons, the development work on their own server, in
favor of other ones (if at all, its likely that their server could become
fairly ubiquitous)?

Gerard Robinson, UNC-CH School of Medicine, Office of Information Systems