Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!think!ames!amdahl!pyramid!voder!blia!billc
From: billc@blia.BLI.COM (Bill Coffin)
Newsgroups: comp.databases
Subject: Re: Database Machines
Message-ID: <2878@blia.BLI.COM>
Date: Thu, 25-Jun-87 16:30:04 EDT
Article-I.D.: blia.2878
Posted: Thu Jun 25 16:30:04 1987
Date-Received: Sat, 27-Jun-87 04:58:51 EDT
References: <2861@blia.BLI.COM> <2918@zen.berkeley.edu> <131@hippo.UUCP>
Organization: Britton Lee, Los Gatos, CA
Lines: 27
Keywords: servers vs. distrib is more interesting...

In article <131@hippo.UUCP>, eric@hippo.UUCP (Eric Bergan) writes:

> 	Bill - do you envision a single server approach also being
> desirable in the case of a geographically distributed system, where the
> sites are primarily autonomous, but some data replication and cross
> site queries are good? How would you design such a system?

Of course not.  This is the classic case where a distributed dbms is
exactly what's wanted.  I think there are many cases where you can
change a few of those requirements and find that a server will do.
For instance, salesmen who carry laptops and occasionally dial in
updates or queries.  Or systems where security is critical.

Anyway, servers and distributed dbms's are not necessarily mutually
exclusive.  The classic distrib model has single machines in separate
cities (this is the model shown on the teacher's blackboard when
"distributed databases" is the day's topic).  This is probably
unrealistic; nodes on a distributed system could include several
dissimilar LANs connected by long-haul lines and/or gateways. 
A LAN is a great place for a server.  A distributed dbms could 
be built on top of this model, treating the whole LAN, via its server, 
as a single node in the distributed dbms.

-- 
W.H.Coffin.  billc@blia.BLI.COM (ucbvax!{mtxinu|ucsfcgl}!blia!billc)
 >> the usual disclaimer about my employer and my wretched opinions. <<
 >> the usual witticisms that swell netnews to ridiculous proportions. <<