Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!ogicse!milton!hlab
From: GENOL%UCCMVSA.BITNET@uccvma.ucop.edu (Genevieve Engel)
Newsgroups: sci.virtual-worlds
Subject: Re:  Databases and VR
Message-ID: <1991May29.060526.6941@milton.u.washington.edu>
Date: 29 May 91 01:17:24 GMT
Sender: hlab@milton.u.washington.edu (Human Int. Technology Lab)
Organization: University of Washington
Lines: 51
Approved: cyberoid@milton.u.washington.edu



>
> One of the largest classes of computer applications is database
> management systems.  As a database manager I'm interested in what
> can virtual reality bring to database management and how will
> virtual reality change how we conceptualize data.
>

Never occurred to me that a VR interface would affect the
organization of the data itself.  I would have expected, in the
case of the database here for example, that our existing DBMS and
files would remain in place, but the whole superstructure of code
and screens that we now use for an interface would be replaced by a
VR approach.

I can see your point about this whole thing being difficult to
accomplish with a relational database, but I'm not sure it's
impossible.  Depending on how you set things up, you could
conceivably retain all the same records and get all the information
for presenting them in your VR shell from somewhere else -- a
separate database, one would hope, otherwise from the interface
code itself (blaaarrghh).  (The weird thing about our data is we
don't own it so we're hesitant to go throwing lots of new stuff
into the record.  We don't even edit errors as it is.  So if we
wanted to keep VR-related information around we would have to keep
it anywhere but in the record itself, probably.)

I guess a great big problem for our database is that we have over 6
million records in it -- actually, we have several databases and
that's the biggest one; the others also have multi-millions of
records -- and we get up to 400 concurrent users on our system, so
response time is already a problem.  I just don't see any way the
major portion of the VR interface could reside centrally with the
database without bringing the system to a near halt.  We would
probably have to decentralize the user interface completely.

I'm glad to see you asking these questions about the design of
databases for use with VR systems, but if this really becomes an
issue for database designers, then the even bigger issue will be
how to fit existing databases into a VR shell.  This is going to
have to be pretty modular or it will never get anywhere.

Disclaimer:  I just goof around with the interface and stay
completely uninvolved with the database itself, so a lot of this
is sheer speculation.

Genevieve Engel
GENOL@UCCMVSA.BITNET
MELVYL System User Services
University of California