Path: utzoo!attcan!uunet!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!novavax!rm1!bapat
From: bapat@rm1.UUCP (Bapat)
Newsgroups: comp.databases
Subject: Re: Relational Database, with a Graphical type field
Keywords: Database to store/handle Graphics
Message-ID: <882@rm1.UUCP>
Date: 28 Jun 90 13:13:04 GMT
References: <1176@abcom.ATT.COM> <897@dgis.dtic.dla.mil>
Organization: the boundary between UNIX and sanity
Lines: 30

In <897@dgis.dtic.dla.mil> jkrueger@dgis.dtic.dla.mil (Jon) writes:

>brr@abcom.ATT.COM (Rao) writes:

>>	I am trying to write a relational database
>>	that can be used to store graphical images
>>	...file name as string, reference to graphical file

>Then no atomic, serializable updates.  Is this OK?

Why is that? Why can I not update the graphical field atomically?
If I'm only doing single-transaction updates, why would serializability
be a concern?

>>	...a binary field to hold a large graphical image

>Lacks operations on columns of this type.
>It's unstructured and essentially display-only.

Agreed. One cannot do pattern matches on large binary data fields. For example,
one couldn't say 
   "select mug_shot from employee where <the employee wears glasses>."

Could a graphical type field be implemented as a blob?
(How do vendors implement blobs anyway?)
-- 
Subodh Bapat              bapat@rm1.uu.net     OR           ...uunet!rm1!bapat
MS E-204, P.O.Box 407044, Racal-Milgo, Ft Lauderdale, FL 33340  (305) 846-6068

"In the great journey of life, I seem to have lost my boarding pass."