Path: utzoo!attcan!uunet!mailrus!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!ncar!mephisto!rutgers!mcdchg!tellab5!segel
From: segel@Tellabs.COM (Mike Segel)
Newsgroups: comp.databases
Subject: Re: Relational Database, with a Graphical type field
Message-ID: <2873@tellab5.tellabs.com>
Date: 27 Jun 90 17:34:17 GMT
References: <1700.26863d4e@spacm1.uucp> <898@dgis.dtic.dla.mil> <1189@abcom.ATT.COM>
Organization: Tellabs, Inc. Lisle IL
Lines: 74

In article <1189@abcom.ATT.COM> brr@abcom.ATT.COM (Rao) writes:

First, let me stress that I am not working for Informix, and that
my posting is an educated guess not necessarily true. (Maybe Dr.
Scump aka Col. Panic can verify :-)

	The functionality you are looking for can be found in the multi
media DB Online by Informix. (Multimedia, cute little buzzword no?)
I belive Silicon Graphics introduced a product based on Informix's 
standard engine as well.

>
>	I would like to put forth the following necessary
>	functionality:
>
>	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. In Online I believe it is a pointer to the DB space which
holds all of the images specified by the table. I think what SG did was
to have a field store the FD of the image and actually put locks on the 
file when that tuple was accesed, regardless if the image was shown.

>	2) To be able to change the attributes (i.e. charecteristics)
>	   of the graphical field.
>
	This is more of a function of the front end. The database
need only consider the image to be a large Binary Blob. Sort of
abstracts the data. #2 seems to be application dependant.

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

>	4) To implement all operations that are possible
>	   on generic fields using SQL, 
>	   i.e. Insert, Update, Make Null, etc.
>
>	5) Aditionally, to be able to zoom, reduce size, rotate, etc.
>	   graphical operations on the graphical field.
>
	#4 is a given, 'cept NULL would be difficult to explain.
#5 is really a process of the front end.

>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. [Guys don't flame me for this
one. OK?]
>
>Would like to invite suggestions/additions from netters
>and even other approaches.
>
 Why reinvent the wheel? I think Oracle might have a BLOB field, as well so
 might SYBASE. What they all lack is a good GUI which takes advantage
 of the back end ability. I think a possible reason for this, is that
such a front end would have to be too generic to be useful, or too
application specific or platform specific. Maybe someone from their companies
could verify?


>-bindu rama rao

-Gargoyle