Path: utzoo!attcan!uunet!dev!dgis!jkrueger
From: jkrueger@dgis.dtic.dla.mil (Jon)
Newsgroups: comp.databases
Subject: Re: Relational Database, with a Graphical type field
Message-ID: <913@dgis.dtic.dla.mil>
Date: 5 Jul 90 16:59:02 GMT
References: <1189@abcom.ATT.COM> <2873@tellab5.tellabs.com> <6207@tekgen.BV.TEK.COM> <2895@tellab5.tellabs.com>
Organization: Defense Technical Information Center (DTIC), Alexandria VA
Lines: 33

segel@tellabs.com (Mike Segel) writes:

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

By using appropriate storage structures, access methods, sort
algorithms, query decomposition (might reduce rows to be sorted based
on other query terms, even eliminate the need for sort if 0 or 1
returned row).

>Or keep a multituple view in memory?

Not a problem.  Perhaps a solution to some other, unstated, problem.
Besides "which memory", etc., e.g. how to distribute over net.

>You are decreasing the performance of your engine if you actually try
>to store the image as part of the tuple.

Neither true nor false.  Which usually indicates you aren't honing
in on the right issues.  "ADT's don't kill performance, people
who don't know how to use them kill performance"  :-)

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

What would be an example of this?  To weigh against all the
counter-examples.

-- Jon
-- 
Jonathan Krueger    jkrueger@dtic.dla.mil   uunet!dgis!jkrueger
Drop in next time you're in the tri-planet area!