Path: utzoo!attcan!telly!problem!compus!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!intrbas!kenn
From: kenn@intrbas.uucp (Kenneth G. Goutal)
Newsgroups: comp.databases
Subject: Re: database containing gray-scale graphic images
Summary: Interbase works great in multivendor environments
Keywords: gray-scale graphic images blobs
Message-ID: <123@intrbas.UUCP>
Date: 21 Dec 90 18:04:33 GMT
References: <1990Dec19.181537.10103@usenet.ins.cwru.edu> <117@intrbas.UUCP> <1094@cortex.med.jhu.edu>
Sender: news@intrbasintrbas.UUCP
Organization: Interbase Software Corporation
Lines: 87
Nntp-Posting-Host: krebs

In article <1094@cortex.med.jhu.edu> (Jim Rosenberg) writes:

>Will Interbase run on a DEC workstation network (3100's running off of
>a 5400 server) running Ultrix ?  

I will have to check to make sure about the 5400,
but I know we have it running on 3100's here.
And yes, they all talk to each other.
An application on node A can bring up a db on node B and another on node C
and perform inquiries involving the two of them and display the results
on node A.

>How is the speed on retrieving and storing images in these RDBMS's ?  

That, unfortunately, is rather hard to say a priori.
Performance always depends on so many factors that we can measure them
all in a 'laboratory environment' and make sensible predictions.
Your best bet is to do some benchmarks in your own environment.

>Are there ANY limits on the size of the "blob."  

The limit in Interbase is the size of a longword.
We may actually use only 31 bits, but you get the idea.

>Is there a clear 
>relationship between performance and the size of the blob (aside from 
>system throughput constraints) ?  

I'll have to pass on this one for now.

>Does the inclusion of "blobs" affect 
>the performance of the RDBMS in handling queries / updates of "traditional"
>domains such as "name" or "age" ?  

Depends.  If I retrieve only the traditional fields from records containing
blobs, then only those fields are passed across the network.
If the retrieval is not constrained by doing a string search on the
contents of the blob (unlikely in your case), then there it is probable
that the access method won't have to drag the blobs in off disk at all;
the blob fields are still not sent to the user's program unless asked for.
Naturally, if you *do* ask for the blob fields as well as the traditional
fields, there is just that much more data to be passed back and forth.

>Can calls for "blobs" be embedded in "C" programs ? 

Certainly!

How do these RDBMS's compare with "non-blob" RDBMS's in general 
>(query languages, 4GL's, form makers and report writers) ?

Interbase supports both SQL and our proprietary query language GDML.
Our blob support in SQL is done in such a way as not to require extensions
to the SQL syntax.  We have an interactive query interface called QLI;
blobs are handled in QLI essentially to the extent that there is a blob
filter that can convert the blob to ASCII for printing.  QLI has a
report writer built into it.  Interbase includes a forms package called
PYXIS that can be used both from QLI and from applications coded in your
favourite 3GL.  Forms support blobs to the extent that they are text;
I'd have to check to see if blob filters are automatically invoked.

>We are a medical imaging research lab with approx. 2500 image series on 
>approx. 1000 subjects.  An "image series" consist of between 10 and 60
>individual images, all in a file between 3Mb and 10Mb.  

I.e. your images currently occupy a total of 
something like 7500Mb to 25000Mb ?

>would require embedding queries for the images into "C" and "X Windows" 

We have customers who have developed applications that use DECwindows,
writing in C.

>Speed of access is the critical factor in
>determining the feasibility of using an RDBMS:  our users need those images
>in (very few) seconds.

Again, I would strongly recommend working out some sort of benchmark
that will give you an accurate representation of expected performance
based on a model of your application.

-- Kenn Goutal
   Technical Support

Interbase Software Corporation
209 Burlington Road			...!linus!intrbas!kenn
Bedford  MA  01730			...!uunet!intrbas!kenn
617.275.3222