Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!pasteur!eden!mao
From: mao@eden (Mike Olson)
Newsgroups: comp.databases
Subject: Re: More on image databases
Message-ID: <21789@pasteur.Berkeley.EDU>
Date: 5 Feb 90 23:46:21 GMT
References: <15498@orstcs.CS.ORST.EDU>
Sender: news@pasteur.Berkeley.EDU
Reply-To: mao@postgres.Berkeley.EDU (Mike Olson)
Followup-To: comp.databases
Organization: University of California, Berkeley
Lines: 42

In article <15498@orstcs.CS.ORST.EDU>, Curt Vandetta (curt3028@oce.orst.edu)
writes:

>  I've been reading the discussion here about an image database
>  and I'm quite interested in this myself.  ...
>  I'm more than convinced that I will need to migrate to an object
>  oriented model to keep the images in the database themselves, and 
>  I'm in the process of coming to speed on the object oriented approach.
>  So please for give me if this next question is obvious, but what I
>  hope to do (someday), is have the database setup in such a way that
>  the end-user can do querys on say, pixel values inside of an image.
>  ...
>  Now before I spend years on the object oriented model, is this
>  kind of thing even possible under the object oriented or even
>  relation model?

this is a pretty interesting application; i can't point you at a system
that'll do what you want today, but i have some observations.

there's no a priori reason that you *can't* do this on a relational system.
what you need is abstract data types (ADTs).  you write code that "imports"
and "exports" the data for the relational system, and you write code that
does the sort of searches you need.  then you register these functions
with the database.  it calls your funcs to read and write the data; when
you run a query on the data, it calls your functions.  there are details
i'm glossing over, but this is the basic idea.

you can argue that this is an object-oriented approach, if you like, but
relational system vendors are moving toward this sort of functionality.

the real problem you have is that the values you want to store are enormous.
given that a single value for you is 512x512x8 bits, you need to store
262,144 bytes in a single logical write.  that means that you need enormous
tuples.  i suspect that vendors of dedicated oodb systems, as well as
relational vendors, will have a problem with this.

i'd be interested in hearing what sort of solutions you come up with.

					mike olson
					postgres research group
					uc berkeley
					mao@postgres.berkeley.edu