Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekgen!tekcae!moiram
From: moiram@tekcae.CAX.TEK.COM (Moira Mallison)
Newsgroups: comp.databases
Subject: Re: Relational Database, with a Graphical type field
Message-ID: <6207@tekgen.BV.TEK.COM>
Date: 28 Jun 90 17:44:26 GMT
References: <1700.26863d4e@spacm1.uucp> <898@dgis.dtic.dla.mil> <1189@abcom.ATT.COM> <2873@tellab5.tellabs.com>
Sender: news@tekgen.BV.TEK.COM
Reply-To: moiram@tekcae.CAX.TEK.COM (Moira Mallison)
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 51

In article <2873@tellab5.tellabs.com> segel@Tellabs.COM (Mike Segel) writes:
>>	1) To be able to update the graphical entry of a tuple.
>>
>	This gets to be tricky. It is not efficient to actually store
>the image as part of the tupple, instead actually store a pointer to
>the image. 

The problem with this is that you lose one of the important aspects
of the relational model, ie all the data resides in relations.
Now, some of the attributes hold data, and some hold pointers, and
it's up to the application to know what to do with the pointers.
I don't see this as a step forward.

>>	3) To be able to compare two fields of type "graphical".
>>		This might be the hardest to define. A Griphics Guru
>>		can be of help here.
>>
>	This is definately application dependant. Who knows what you
>are storing in the BLOB. It could be a voice mail message, or some
>non-visual binary field.

Advances in database technology will ideally make the DBMS smarter.
A BLOB does not.  "All I've got is a whole bunch of bytes.  I don't
know what to do with them.  You better figure that out."  The more
information that can be stored in the DBMS, the less effort will
be expended to build applications around it.   What is stored in
the DBMS can be more easily shared and re-used.

>>Guess an object -oriented database is better for such a
>>requirement, where function (operator) overloading can be
>>used by polymorphism.
>>
>	I tend to disagree. Most applications which people say require
>an OODBMS can be done on a relational DBMS. Granted I don't know much about
>OODBMS's (I am still reading up on them when I get the time) but there is
>a lot which can be done in relational tupples, if one takes an abstract
>look at the data for a long enough period. 

There is a lot that can be done with the relational model, but that
doesn't mean that the relational model can be all things to all 
people.  And some things that can be done with the relational model
cannot necessarily be done EASILY with the relational model.   One
of the attractive aspects of the relational model is it's simplicity
and it's rigor.  But you start to lose that when you start storing
pointers to other objects (get it?) in your attributes.  If that's
what you need to do, get a DBMS that more fully supports the operations
on the data.

Moira Mallison
CAx Data Management
Tektronix, Inc