Re: Implementation of Grid File

Interesting concept. So what's the difference between what you have discussed and z-ordering b-trees? Excuse the ignorance but do b-trees not need to have atomic single dimensional data. So, if C&D was to be indexed then what values would be stored in the nodes?

I have been looking at hash table, however they are un usable due to there lack of performance when dealing large amount of data and single indexing properties.

.
Regards

John

"Benjamin Johnston" <superhero_at_benjaminjohnston.com.au> wrote in message news:kOpR9.16077$jM5.44303_at_newsfeeds.bigpond.com...
> > I was
> > considering B-Tree's however, that would require 24 in total (4*3*2*1),
as
> > any mix of columns could be used for the seed of the query (C&D, B&C).
>
> If order does not matter (ie. a query involving C & D is equivalent to D &
> C) then you've only got 15 in total.
>
> And if, as you said in a previous posting, there is a maximum of two query
> columns (and order does not matter), there's only 10 indexes.
>
>
> And if you're using B-trees, you can do with just 6. Consider these
indexes:
> ABCD, ACD, BCD, DA, BD, CD
> Since order doesn't matter and we're considering B-trees, you can use ABCD
> for a query on A, AB, BA, ABC, ACB, BCA, BAC or ABCD.
> (ie. any permutation of a prefix of an index).
>
> > The reason I was considering the implementation of Grid file is that it
> has
> > two disc access, which would be efficient for the application.
> >
> > So what about a happy median? a multi-dimensional data structure with
> > efficient disk access? Could R-Tree be used in such a way
>
> A kd-tree might be appropriate.
>
> Alternately, I have the feeling you've got few enough rows to be able to
use
> a couple of smaller B-tree or hash indexes (say just A,B,C,D and maybe
even
> some composite indexes) and filter, in memory, the result of a less
specific
> query.
>
> Personally, I'd go with the 6 B-tree indexes: ABCD, ACD, BCD, DA, BD, CD
>
> -Benjamin Johnston
>
>
>
Received on Sat Jan 04 2003 - 13:02:20 CET