Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!decwrl!nsc!pyramid!infmx!davek
From: davek@infmx.UUCP (David Kosenko)
Newsgroups: comp.databases
Subject: Re: Relational Database, with a Graphical type field
Message-ID: <4674@infmx.UUCP>
Date: 3 Jul 90 15:39:19 GMT
References: <1700.26863d4e@spacm1.uucp> <898@dgis.dtic.dla.mil> <1189@abcom.ATT.COM> <2873@tellab5.tellabs.com> <6207@tekgen.BV.TEK.COM>
Reply-To: davek@infmx.UUCP (David Kosenko)
Organization: Informix, Menlo Park, Ca. U.S.A.
Lines: 67

In article <6207@tekgen.BV.TEK.COM> moiram@tekcae.CAX.TEK.COM (Moira Mallison) writes:
>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.
>

	Mr. Segel was somewhat incorrect in his description of 
INFORMIX-OnLine's treatment of BLOB data types in this respect.  There
is the ability, internal to the database engine, to store actual BLOB
data in a physical space seperate from the rest of the data.  This is
done for various reasons, most relating to efficiency of access.  What
is stored, again internal to the database, in the actual tuple data is
a pointer to the location of this BLOB data; however, to the end user,
this data is still held in the relation itself.  You do not need to know
about this internal structure in your applications, and the relational
model is maintained.  I hope you can see this implementation 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.
>

	Yes, and BLOBs do fit this criteria.  The ability to store
arbitrarily large data items in a relation, and have it accessible to
all who can query that relation does, in many ways, "make the DBMS smarter."



Dave Kosenko

n
e
w
s
f
o
d
d
e
r

-- 
Disclaimer:  The opinions expressed herein | There's more than one answer
are by no means those of Informix Software | to these questions pointing me
(though they make you wonder about the     | in a crooked line...
 strange people they hire).                |