Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!tellab5!segel
From: segel@tellabs.com (Mike Segel)
Newsgroups: comp.databases
Subject: Re: Relational Database, with a Graphical type field
Message-ID: <2895@tellab5.tellabs.com>
Date: 29 Jun 90 17:57:29 GMT
References: <1189@abcom.ATT.COM> <2873@tellab5.tellabs.com> <6207@tekgen.BV.TEK.COM>
Sender: news@Tellabs.COM
Organization: Tellabs, Inc. Lisle IL
Lines: 69

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.
>

	Well, the problem arises when you now have each tuple being 1 - 2 Meg
	in size. So now how do you efficiently sort on non graphic data?
	Or keep a multituple view in memory?
	What I am saying, is that the database stores a pointer to where the
	graphical information is stored. For example, I BELIEVE Informix's Online
	stores a pointer to the Blob area inside the database. When the end user
	/ applications programmer goes to fetch the blob, he does not see this,
	he/she will fetch it like it is part of the tuple. (Again I am assuming
	this, perhaps someone from Informix will elaborate.) My point is, that
	You are decreasing the performance of your engine if you actually try
	to store the image as part of the tuple. Whether you let the application
	see the pointer, or keep it internal to the engine, is up to you.

>>>	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.
>
	What sort of information is contained in the blob is application
	dependant. I prefer to take the minimalist approach in designing
	back-ends. The less intelligent the backend, the greater ability 
	to treat data in an abstract fashion. Yes, it puts more emphasis
	on the 4GL or front-end, but it allows for a wider range of potential
	applications to be developed.
		Now, not being an object oriented guru,  I thought that if I were
	designing an OODBMS, I would keep the backend as simple as possible
	and let the front end do all the work.

>and it's rigor.  But you start to lose that when you start storing
>pointers to other objects (get it?) in your attributes. 
	Not really. How the back-end stores the information should be a black
	box to the front-end. As long as the front end can get the information
	in a timely fashion.
>
>Moira Mallison

-Mike Segel


--
Mike Segel         | uunet!balr.com                    | Std.disclaimer 
BALR Corporation   | segel@quanta.eng.ohio-state.edu   | implied and 
Oakbrook, Illinios | uunet!tellabs.com!segel           | understood
-------------------^-----------------------------------^----------------